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Abstract 


The  ML  module  system  stands  as  a  high-water  mark  of  programming  language  support  for 
data  abstraction.  Nevertheless,  it  is  not  in  a  fully  evolved  state.  One  prominent  weakness  is  that 
module  interdependencies  in  ML  are  restricted  to  be  acyclic,  which  means  that  mutually  recursive 
functions  and  data  types  must  be  written  in  the  same  module  even  if  they  belong  conceptually  in 
different  modules.  Existing  efforts  to  remedy  this  limitation  either  involve  drastic  changes  to  the 
notion  of  what  a  module  is,  or  fail  to  allow  mutually  recursive  modules  to  hide  type  information 
from  one  another.  Another  issue  is  that  there  are  several  dialects  of  ML,  and  the  module  systems 
of  these  dialects  differ  in  subtle  yet  semantically  significant  ways  that  have  been  difficult  to  account 
for  in  any  rigorous  way.  It  is  important  to  come  to  a  clear  assessment  of  the  existing  design  space 
and  consolidate  what  is  meant  by  “the  ML  module  system”  before  embarking  on  such  a  major 
extension  as  recursive  modules. 

In  this  dissertation  I  contribute  to  the  understanding  and  evolution  of  the  ML  module  system 
by:  (1)  developing  a  unifying  account  of  the  ML  module  system  in  which  existing  variants  may 
be  understood  as  subsystems  that  pick  and  choose  different  features,  (2)  exploring  how  to  extend 
ML  with  recursive  modules  in  a  way  that  does  not  inhibit  data  abstraction,  and  (3)  incorporating 
the  understanding  gained  from  (1)  and  (2)  into  the  design  of  a  new,  evolved  dialect  of  ML.  I 
formalize  the  language  of  part  (3)  using  the  framework  of  Harper  and  Stone,  in  which  the  meanings 
of  “external”  ML  programs  are  interpreted  by  translation  into  an  “internal”  type  system. 

In  my  exploration  of  the  recursive  module  problem,  I  also  propose  a  type  system  for  statically 
detecting  whether  or  not  recursive  module  definitions  are  “safe” — that  is,  whether  they  can  be 
evaluated  without  referring  to  one  another  prematurely — thus  enabling  more  efficient  compilation 
of  recursive  modules.  Future  work  remains,  however,  with  regard  to  type  inference  and  type  system 
complexity,  before  my  proposal  can  be  feasibly  incorporated  into  ML. 
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Introduction 


Nearly  all  programming  languages  that  are  intended  for  the  implementation  of  real-world  appli¬ 
cations  provide  some  facility  for  structuring  programs  as  a  network  of  smaller  modules.  While 
structuring  a  program  in  this  fashion  typically  incurs  some  initial  development  overhead,  it  also 
reaps  several  huge  rewards.  First,  it  allows  multiple  programmers  to  work  on  different  modules  of 
the  same  program  simultaneously.  Second,  it  delineates  the  high-level  structure  of  the  program, 
which  in  turn  makes  the  program  easier  to  understand  and  maintain.  Third,  it  can  make  the 
program  significantly  more  reliable  through  the  use  of  data  abstraction. 

The  idea  of  data  abstraction  is  that  the  weaker  the  dependencies  between  program  modules, 
the  more  robust  the  program  structure  will  be.  In  particular,  for  the  purpose  of  enforcing  program 
invariants,  it  is  useful  for  the  implementor  of  a  module  to  be  able  to  hide  information  from  clients 
of  the  module  regarding  the  structure  of  data  that  it  operates  on.  For  example,  the  correctness 
of  a  module  implementing  binary  search  trees  as  red-black  trees  depends  on  the  invariant  that  the 
trees  it  operates  on  have  no  two  adjacent  red  nodes.  The  tree  operations  provided  by  the  module 
assume  this  invariant  about  the  trees  they  are  given  as  input  and  preserve  this  invariant  for  the 
trees  they  produce  as  output.  To  ensure  that  the  input  assumptions  are  valid,  the  implementor 
should  be  able  to  restrict  the  clients  of  the  module  so  that  they  may  only  construct  red-black 
trees  via  the  invariant-preserving  operations  that  the  module  provides.  Such  a  restriction,  which 
constitutes  a  weakening  of  the  dependency  between  the  module  and  its  clients,  also  makes  the  client 
code  more  reusable.  One  may  make  arbitrary  changes  to  the  implementation  of  the  binary  search 
tree  module  without  precipitating  changes  to  its  clients,  so  long  as  the  external  functionality  of  the 
module — i.e.,  the  set  of  operations  it  provides — remains  the  same. 

Many  modern  programming  languages  provide  some  form  of  support  for  data  abstraction.  For 
example,  in  mainstream  object-oriented  languages  like  C-|— I-  and  Java,  “classes”  support  data 
abstraction  by  allowing  certain  fields  or  methods  of  a  class  to  be  designated  as  “private”  and 
therefore  invisible  to  the  clients  of  the  class.  However,  classes  also  embody  a  host  of  other  features 
of  object-oriented  programming,  such  as  inheritance,  subtyping  and  dynamic  dispatch.  The  subtle 
and  sometimes  undesirable  interplay  of  these  features  makes  classes  a  tricky  object  for  formal  study. 

In  this  dissertation  I  will  be  exploring  an  altogether  different  approach  to  modular  program¬ 
ming,  namely  that  of  the  ML  module  system.  Unlike  the  class  mechanism  in  object-oriented 
languages,  the  module  mechanism  in  ML  is  focused  entirely  on  supporting  data  abstraction.  It 
ensures  implementor- side  data  abstraction  by  allowing  the  implementor  of  a  module  to  “seal”  it 
behind  an  abstract  interface,  thereby  hiding  information  about  its  internal  data  representation  from 
its  clients.  Furthermore,  ML’s  notion  of  an  interface  is  very  flexible,  enabling  one  to  reveal  partial 
information  about  the  identity  of  an  abstract  data  type  or  to  express  equivalences  between  abstract 
data  types  exported  by  different  modules.  ML  also  exploits  a  form  of  client-side  data  abstraction 
through  the  “functor”  mechanism.  Functors,  which  are  functions  at  the  level  of  modules,  allow  one 
to  develop  and  compile  a  module  independently  from  the  modules  on  which  it  depends,  given  only 
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abstract  interfaces  for  them.  These  dependencies  can  then  be  instantiated  with  multiple  different 
modules  during  the  execution  of  the  program,  enabling  a  powerful  form  of  code  reuse.  ^ 

Nevertheless,  despite  its  strengths,  the  ML  module  system  is  not  in  a  fully  evolved  state.  One 
prominent  weakness  is  that  module  interdependencies  in  ML  are  restricted  to  be  acyclic,  which 
means  that  mutually  recursive  functions  and  data  types  must  be  written  in  the  same  module  even 
if  they  belong  conceptually  in  different  modules.  In  addition  to  hindering  independent  development 
of  mutually  recursive  components,  this  restriction  inhibits  data  abstraction  because  it  prevents  mu¬ 
tually  recursive  components  from  hiding  implementation  details  from  one  another.  Furthermore, 
although  there  are  justifications  for  ML’s  restriction,  it  still  seems  rather  unintuitive  to  most  new¬ 
comers  to  the  language,  who  are  accustomed  to  languages  like  Java  and  C-|— |-  that  do  allow  cyclic 
dependencies  between  program  components.  As  a  consequence,  support  for  mutually  recursive 
modules  has  been  one  of  the  most  frequently  requested  extensions  to  ML. 

In  response,  there  has  been  much  work  in  recent  years  on  extending  ML  and  other  functional 
languages  with  recursive  modules.  Most  of  the  current  proposals  suggest  replacing  ML  modules 
with  some  alternative  mechanism  such  as  “units”  or  “mixins,”  which  are  subject  to  severe  syntactic 
restrictions  but,  as  a  result,  are  easier  to  recursively  link  [20,  16].  The  only  concrete  proposals  that 
remain  within  the  framework  of  ML  modules  are  Russo’s  extension  to  the  Moscow  ML  compiler  [66] 
and  Leroy’s  extension  to  the  Objective  Caml  compiler  [44].  Both  of  these  are  based  to  a  large  extent 
on  Crary  et  al.’s  foundational  account  of  recursive  modules  [6].  Neither  extension,  however,  provides 
full  support  for  data  abstraction  between,  or  separate  compilation  of,  mutually  recursive  modules. 

Before  we  can  consider  ways  of  improving  on  the  existing  proposals  for  extending  ML  with 
recursive  modules,  there  are  two  more  basic  questions  that  need  to  be  addressed.  First,  what 
language  should  we  be  extending?  There  is  not  just  one  language  called  ML;  there  are  several 
dialects  of  ML,  the  most  popular  being  Standard  ML  (SML)  [52]  and  Objective  Caml  (O’Caml)  [41]. 
These  implemented  dialects  are  both  the  result  of  and  inspiration  for  a  large  body  of  research  on 
the  theoretical  underpinnings  of  ML  and  in  particular  its  module  system.  However,  as  these  formal 
accounts  of  the  ML  module  system  employ  a  variety  of  different  formalisms,  the  relationships  and 
tradeoffs  between  different  designs  have  been  difficult  to  understand  or  compare  in  a  rigorous  way. 
It  is  important  that  we  come  to  a  clear  assessment  of  the  existing  design  space  and  consolidate  what 
is  meant  by  “the  ML  module  system”  before  embarking  on  such  a  major  extension  as  recursive 
modules. 

Second,  once  we  decide  on  the  basis  for  our  extension,  what  is  the  right  way  to  go  about  defining 
the  extension?  Type  theory  and  operational  semantics  have  proven  to  be  an  ideal  setting  for  defin¬ 
ing  and  reasoning  about  fundamental  concepts  like  polymorphism,  data  abstraction  and  subtyping, 
with  established  methods  for  proving  properties  like  type  safety  and  decidability  of  typechecking. 
However,  while  there  exist  a  number  of  type-theoretic  accounts  of  ML-style  modularity,  they  typ¬ 
ically  describe  some  idealized  subset  of  the  ML  language.  On  the  other  hand,  the  Standard  ML 
dialect  has  been  given  a  full  formal  definition,  and  the  very  existence  of  the  Definition  of  SML  [52] 
has  encouraged  the  development  of  independent  implementations  of  the  language  while  providing 
stability  of  SML  code  across  those  implementations.  The  flip  side  of  that  stability  is  that  the 
Definition  is  closely  tailored  to  the  needs  of  SML,  often  to  the  point  of  seeming  ad  hoc  from  a  more 
general  semantic  perspective.  For  example,  it  is  not  clear  how  the  “semantic  object”  language  that 
the  Definition  uses  to  formalize  SML’s  static  semantics  corresponds  to  traditional  type  structures. 

The  approach  I  take  in  this  dissertation  follows  the  work  of  Harper  and  Stone  [33] ,  who  give  an 
alternative  interpretation  of  Standard  ML  by  translating  well-formed  SML  programs  into  a  type 

will  give  concrete  examples  of  how  ML’s  sealing  and  functor  mechanisms  are  used  in  Chapter  1.  For  a  detailed 
comparison  of  the  ML  approach  and  the  object-oriented  approach  to  modularity,  see  MacQueen  [48]. 


INTRODUCTION 


3 


theory.  The  Harper-Stone  approach  provides  one  with  a  flexible  method  of  evolving  a  full-fledged 
programming  language.  The  key  concepts  of  the  language  are  modeled  at  the  level  of  the  type 
theory,  where  they  can  be  more  clearly  understood.  The  features  of  the  language  that  are  not  so 
much  semantically  interesting  as  syntactically  convenient — e.g.,  type  inference,  pattern  matching, 
the  open’ing  of  a  module’s  namespace — are  handled  by  the  translation  (called  elaboration),  which 
formalizes  how  these  features  are  to  be  de-sugared  into  more  basic  constructs. 

Another  advantage  of  the  Harper-Stone  approach  is  that  it  fits  neatly  into  the  model  of  type- 
directed  compilation  [31,  77,  70,  68].  In  traditional  compilers,  type  information  is  discarded  after 
typechecking.  In  type-directed  compilers,  the  intermediate  languages  of  the  compiler  are  typed 
so  as  to  enable  optimizations  that  rely  on  type  information.  For  instance,  the  TILT  compiler  for 
SML  developed  at  CMU  [77,  74,  61]  maintains  type  information  throughout  compilation  in  order 
to  implement  intensional  type  analysis  [31]  and  tag-free  garbage  collection  [55].  Thus,  regardless  of 
how  ML  programs  are  typechecked,  a  type-directed  ML  compiler  will  at  some  point  need  to  translate 
them  into  an  internal  typed  language.  TILT  performs  this  translation  as  part  of  typechecking,  based 
closely  on  Harper  and  Stone’s  elaboration  algorithm. 

In  summary,  the  goal  of  this  dissertation  is  to  contribute  to  the  evolution  of  the  ML  module 
system  in  the  following  ways: 

Part  I:  To  develop  a  unifying  account  of  existing  variants  of  the  ML  module  system  that  can  serve 
as  a  basis  for  future  research  on  module  systems. 

Part  II:  To  explore  the  problem  of  extending  ML  with  recursive  modules,  with  the  goal  of  emend¬ 
ing  the  deficiencies  of  existing  proposals. 

Part  III:  To  formally  define  a  language  based  on  the  work  of  Parts  I  and  H  within  the  type- 
theoretic  framework  of  Harper  and  Stone. 

The  document  is  structured  as  follows; 

Part  I:  In  Chapter  1, 1  give  an  overview  of  the  design  space  of  ML  modules,  as  well  as  a  discussion  of 
the  key  ideas  and  motivations  behind  a  variety  of  existing  designs.  In  Chapter  2,  I  give  a  high-level 
semantic  analysis  of  what  makes  ML-style  data  abstraction  work,  leading  to  a  unifying  framework 
in  which  several  variants  of  the  ML  module  system  can  be  understood  as  subsystems  that  pick 
and  choose  different  features.  I  also  describe  the  design  of  a  type  system,  based  on  this  unifying 
framework,  that  harmonizes  and  improves  on  the  existing  designs.  This  type  system  is  formally 
defined  in  Chapters  3  and  4:  the  first  chapter  presents  the  “core”  language  of  the  type  system,  and 
the  second  chapter  presents  the  “module”  language.  In  addition  to  providing  detailed  discussion  of 
the  rationale  behind  various  typing  rules,  these  chapters  present  the  key  meta-theoretic  properties 
of  the  core  and  module  languages,  which  include  type  safety  and  decidability  of  typechecking. 

Part  II:  In  Chapter  5,  I  give  an  overview  of  the  design  space  of  existing  recursive  module  exten¬ 
sions  to  ML  and  discuss  the  deficiencies  of  these  proposals,  which  suggest  two  key  directions  for 
improvement.  One  direction  for  improvement  involves  the  interaction  of  recursive  modules  and  data 
abstraction.  I  describe  (in  Chapter  5)  an  intuitive  semantics  that  allows  for  real  data  abstraction 
between  recursive  modules.  Some  aspects  of  this  semantics  can  be  captured  in  type  theory,  and  in 
Chapter  6  I  show  how  to  extend  the  type  theory  of  Chapters  3  and  4  accordingly.  However,  there  is 
a  significant  component  of  my  intuitive  semantics  for  recursive  modules  that  I  do  not  know  how  to 
account  for  directly  in  type  theory.  I  formalize  it  instead  in  Part  HI  using  elaboration  techniques. 
The  other  direction  for  improvement  on  existing  recursive  module  designs  involves  statically  detect¬ 
ing  whether  a  recursive  module  is  “safe.”  In  Chapter  7,  I  explore  this  direction  in  the  context  of  the 
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simply-typed  A-calculus,  setting  aside  the  orthogonal  issues  involving  type  components  in  modules. 
At  the  end  of  the  chapter,  I  discuss  what  would  be  involved  in  scaling  my  proposed  approach  to 
the  level  of  modules  with  type  components. 

Part  III:  In  Chapters  8  and  9,  I  use  the  Harper-Stone  framework  as  a  starting  point  for  defining 
a  new  dialect  of  ML.  Following  Harper-Stone,  the  language  is  defined  in  two  parts.  The  “internal” 
language,  defined  in  Chapter  8,  is  a  type  system  based  very  closely  on  the  work  of  Chapters  3,  4 
and  6.  The  “external”  programmer-level  language,  defined  in  Chapter  9  by  translation  into  the 
internal  language,  is  an  evolved  dialect  of  Standard  ML  that  supports  recursive  and  higher-order 
modules.  Finally,  in  Chapter  10,  I  conclude  and  suggest  directions  for  future  work. 


Part  I 

U  nderstanding 
the  ML  Module  System 


Chapter  1 


The  Design  Space  of  ML  Modules 


What  is  the  ML  module  system?  It  is  difficult  to  say.  There  are  several  dialects  of  the  ML  language, 
and  while  the  module  systems  of  these  dialects  are  certainly  far  more  alike  than  not,  there  are 
important  and  rather  subtle  differences  among  them,  particularly  with  regard  to  the  semantics  of 
data  abstraction.  The  goal  of  Part  I  of  this  thesis  is  to  offer  a  new  way  of  understanding  these 
differences,  and  to  derive  from  that  understanding  a  unifying  module  system  that  harmonizes  and 
improves  on  the  existing  designs. 

In  this  chapter,  I  will  give  an  overview  of  the  existing  ML  module  system  design  space.  I  begin 
in  Section  l.I  by  developing  a  simple  example — a  module  implementing  sets — that  establishes  some 
basic  terminology  and  illustrates  some  of  the  key  features  shared  by  all  the  modern  variants  of  the 
ML  module  system.  Then,  in  Section  1.2,  I  describe  several  dialects  that  represent  key  points  in 
the  design  space,  and  discuss  the  major  axes  along  which  they  differ. 

1.1  Key  Features  of  the  ML  Module  System 

1.1.1  Structures  aud  Siguatures 

In  ML,  code  and  data  are  grouped  together  in  modules.  The  basic  module  construct  is  called  a 
structure,  and  Figure  1.1  shows  an  example  of  a  structure  implementing  integer  sets.^  The  structure 
IntSet  is  defined  by  a  structure  expression  struct  .  .  .  end,  which  contains  a  sequence  of  bindings. 
The  first  binding  defines  the  type  name  set  as  an  abbreviation  for  the  type  int  list  of  integer  lists, 
thus  indicating  that  sets  are  being  implemented  by  this  module  as  lists.  Type  bindings  are  much 
like  typedefs  in  C;  the  type  set  and  the  type  int  list  are  interchangeable.  The  second  binding  in 
IntSet  is  a  value  binding,  defining  emptyset  to  be  the  empty  list  [] ,  which  has  type  set  because 
it  has  type  int  list.  The  remaining  bindings  are  function  bindings:  an  insert  operation  that 
takes  an  integer  and  a  set  and  returns  the  result  of  pushing  the  integer  onto  the  front  of  the  list 
representing  the  set,  and  a  member  operation  that  checks  whether  an  integer  belongs  to  a  set  by 
performing  a  sequential  search  on  the  list  representing  the  set.^  Although  this  example  does  not 
illustrate  it,  structures  in  ML  may  also  contain  substructure  bindings,  thereby  allowing  modules  to 
be  built  up  as  composites  of  other  modules  and  enabling  flexible  namespace  management. 

Now  that  we  have  defined  this  module  IntSet,  we  can  use  it  essentially  as  we  would  use  an 
object  in  Java  or  a  struct  in  C — by  projecting  out  its  components  using  the  “dot  notation.”  For 

^This  example,  as  well  as  the  others  in  this  section,  is  written  in  Standard  ML  syntax. 

^Note  that,  in  keeping  with  functional  programming  style,  this  is  a  persistent  implementation  of  sets,  e.g.,  inserting 
an  integer  into  a  set  does  not  modify  the  input  set  but  merely  returns  a  new  set  containing  the  integer. 
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structure  IntSet  = 
struct 

type  set  =  int  list 
val  emptyset  :  set  =  [] 

fun  insert  (x  :  int,  S  :  set)  :  set  =  x: :S 
fun  member  (x  :  int,  S  :  set)  :  bool  =  . . . 

end 


Figure  1.1:  ML  Module  for  Integer  Sets 


signature  INT_SET  = 
sig 

type  set 

val  emptyset  :  set 

val  insert  :  int  *  set  ->  set 

val  member  :  int  *  set  ->  bool 

end 

Figure  1.2:  ML  Interface  for  Integer  Sets 


instance,  we  might  define  the  set  S  by  the  following  value  binding: 

val  S  :  IntSet. set  =  IntSet . insert (5 ,  IntSet . emptyset) 

This  defines  S  by  inserting  5  into  the  empty  set.  A  distinguishing  feature  of  ML  modules  is  that, 
in  addition  to  having  data  and  function  components,  they  have  type  components,  such  as  the  set 
type  component  of  IntSet.  Correspondingly,  we  can  also  use  the  dot  notation  to  project  out  the 
type  IntSet .  set,  which  is  the  return  type  of  IntSet .  insert  and  thus  the  type  of  S. 

As  mentioned  above,  IntSet .  set  is  merely  an  abbreviation  for  int  list.  However,  there  is  no 
need  for  clients  of  the  IntSet  module  to  know  this.  In  the  interest  of  data  abstraction,  we  would 
thus  like  to  hide  the  knowledge  that  IntSet.  set  is  equivalent  to  int  list.  This  is  achieved  by 
first  defining  an  interface  that  describes  what  the  clients  do  need  to  know.  In  ML,  interfaces  are 
called  signatures,  and  Figure  1.2  shows  an  appropriately  abstract  signature  for  integer  sets. 

The  signature  INT_SET  is  defined  by  a  signature  expression  sig  . . .  end,  which  contains  a  list  of 
specifications  for  the  components  of  the  IntSet  module.  The  specifications  for  emptyset,  insert 
and  member  are  straightforward,  assigning  to  each  value  component  a  type.  (In  a  functional  lan¬ 
guage  like  ML,  function  components  are  just  value  components  with  arrow  types.)  The  interesting 
specification  is  the  one  for  the  set  type,  which  holds  its  definition  abstract.  A  more  precise  interface 
for  the  IntSet  module  would  replace  INT_ SET’s  abstract  specification  of  the  set  component  with 
the  transparent  specification  type  set  =  int  list,  which  exposes  the  implementation  of  sets  as 
lists.  ML  allows  one  to  specify  type  components  in  interfaces  with  or  without  their  definitions,  thus 
providing  fine-grained  control  over  the  propagation  of  type  information  (see  Section  1.1.3).  In  this 
case,  however,  the  abstract  INT_SET  interface  is  a  more  appropriate  description  of  sets,  as  it  does 
not  allow  clients  to  depend  on  any  particular  implementation  strategy. 
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signature  COMPARABLE  = 
sig 

type  item 

val  compare  :  item  *  item  ->  order 
end 

functor  Set  (Item  :  COMPARABLE)  = 
struct 

type  set  =  Item. item  list 
val  emptyset  :  set  =  [] 

fun  insert  (x  :  int,  S  :  set)  :  set  =  x: :S 
fun  member  (x  :  int,  S  :  set)  :  bool  = 

...  Item. compare (x,y)  ... 


end 


Figure  1.3:  ML  Functor  for  Generic  Sets 


1.1.2  Data  Abstraction  via  Sealing  and  Functors 

Just  defining  the  INT_SET  signature  does  not  do  anything  by  itself.  To  ensure  that  the  clients’  view 
of  IntSet  is  limited  to  what  appears  in  INT_SET,  we  must  seal  IntSet  with  INT_SET,  as  follows; 

structure  IntSet  =  IntSet  :>  INT_SET 

Given  this  new  definition  for  IntSet,  we  may  still  project  out  the  type  IntSet.  set,  but  it  is  not 
known  to  be  equivalent  to  int  list.  Gonsequently,  the  only  way  clients  of  IntSet  can  create 
values  of  type  IntSet .  set  is  by  using  insert  and  emptyset  (and  presumably  other  operations  like 
union  and  intersection),  which  are  explicitly  specified  in  INT_SET.  Although  the  IntSet  example 
does  not  illustrate  it,  sealing  can  also  be  used  to  hide  the  existence  of  certain  value  components  in 
a  module.  We  will  see  an  example  of  this  in  Section  1.2.6. 

Another  distinguishing  feature  of  the  ML  module  system  is  its  functor  mechanism.  Functors 
are  simply  functions  from  modules  to  modules.  Much  as  functions  allow  a  piece  of  code  to  be  reused 
with  different  instantiations  of  its  parameters,  functors  allow  a  module  to  be  reused  with  different 
instantiations  of  the  modules  it  depends  on.  To  continue  the  IntSet  example,  the  implementation 
of  sets  is  largely  indifferent  to  the  type  of  items  stored  in  the  sets  and  would  be  more  useful  if  it 
were  not  restricted  to  sets  of  integers.  The  only  reason  the  type  of  items  matters  at  all  is  that  the 
implementation  of  a  function  like  member  assumes  an  ordering  on  items.  Functors  allow  us  to  make 
the  implementation  of  sets  generic  with  respect  to  the  item  type,  as  shown  in  Figure  1.3. 

First,  we  define  a  signature  COMPARABLE  describing  what  the  set  module  needs  to  know  about 
the  item  type.  This  signature  characterizes  modules  that  provide  some  type  item — which  one  it  is 
is  irrelevant — together  with  a  function  compare  for  ordering  values  of  that  type.  The  Set  module 
is  then  defined  as  a  functor  that  takes  as  input  a  module  Item  of  signature  COMPARABLE  and 
returns  a  module  implementing  sets  containing  items  of  type  Item.  item.  Note  that  the  set  type 
is  now  defined  as  Item,  item  list,  and  the  member  function  invokes  Item,  compare  for  ordering 
Item,  item’s  instead  of  relying  on  integer  comparison. 

We  can  now  generate  sets  of  different  item  types  very  easily.  For  example,  as  shown  in  Fig¬ 
ure  1.4,  we  can  reproduce  the  functionality  of  our  original  IntSet  module  by  first  defining  a  module 
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structure  Intltem  = 
struct 

type  item  =  int 

fun  compare  (x,y)  =  Int . compare (x,y) 
end 

structure  Stringitem  = 
struct 

type  item  =  string 

fun  compare  (x,y)  =  String. compare (x,y) 
end 

structure  IntSet  =  Set (Intltem) 
structure  StringSet  =  Set (Stringitem) 

Figure  1.4;  Instantiating  the  Set  Functor 


Intltem,  which  provides  int  as  the  item  type  along  with  the  built-in  integer  comparison  function, 
and  then  applying  Set  to  Intltem.  If  we  want  to  generate  an  implementation  of  integer  sets  based 
on  a  different  ordering  of  the  integers,  we  can  apply  the  Set  functor  to  an  item  module  with  the 
same  definition  of  the  item  type  but  with  a  different  comparison  function.  A  module  implementing 
sets  of  strings  or  any  other  type  can  also  be  generated  in  a  similar  manner. 

To  summarize,  we  have  seen  two  mechanisms  that  ML  provides  for  supporting  data  abstraction. 
First,  the  sealing  mechanism  supports  implementor-side  data  abstraction  by  allowing  the  imple¬ 
mentor  of  the  set  module  to  hide  information  about  the  implementation  of  sets  from  its  clients. 
Second,  by  thinking  of  the  set  module  as  itself  being  a  client  of  an  item  module  with  an  abstract 
interface,  we  see  that  ML  functors  exploit  the  idea  of  client-side  data  abstraction  to  provide  a 
powerful  form  of  code  reuse. 

1.1.3  Translucent  Signatures 

The  natural  next  step  in  the  development  of  the  Set  example  is  to  combine  ML’s  two  forms  of 
data  abstraction  by  sealing  the  body  of  the  Set  functor  with  an  abstract  signature  that  hides 
the  implementation  of  sets  as  lists.  The  question  is  what  signature  to  use.  Now  that  we  have 
generalized  the  implementation  of  sets  to  support  an  arbitrary  item  type,  the  INT_SET  signature  is 
no  longer  applicable.  The  most  obvious  answer  is  to  use  a  signature  that  replaces  all  occurrences 
of  int  in  INT_SET  with  references  to  Item.  item.  However,  the  type  Item,  item  only  makes  sense 
inside  the  body  of  the  Set  functor,  and  we  would  like  to  be  able  to  define  a  generic  signature  for 
sets  separately  from  this  particular  implementation  of  them. 

One  way  to  define  a  generic  interface  for  sets  would  be  to  allow  a  signature  to  be  parameterized 
by  a  module  [37],  in  which  case  one  could  define  a  parameterized  signature  SET  as  follows; 

signature  SET  (Item  ;  COMPARABLE)  = 
sig 

type  set 

val  insert  ;  Item. item  *  set  ->  set 


end 
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signature  SET  = 

sig 

type  item 

type  set 

val  emptyset 

:  set 

val  insert  : 

item  *  set  ->  set 

val  member  : 

item  *  set  ->  bool 

end 

Figure  1.5;  Generic 

ML  Signature  for  Sets 

functor  Set  (Item  :  COMPARABLE)  = 
struct 

type  item  =  Item. item 
type  set  =  item  list 
...  (*  same  as  before  *)  ... 
end 

:>  SET  where  type  item  =  Item. item 
Figure  1.6:  Sealed  ML  Functor  for  Generic  Sets 


The  body  of  the  Set  functor  could  then  be  sealed  with  the  signature  SET(Item). 

In  fact,  however,  one  need  not  introduce  an  explicit  form  of  parameterized  signature  in  order 
to  characterize  a  generic  interface  for  sets.  ML  provides  implicit  support  for  parameterized  sig¬ 
natures  through  the  idea  of  translucency.  As  we  have  seen,  type  components  in  ML  signatures 
may  be  specified  “opaquely”  {e.g.,  type  set),  but  they  may  also  be  specified  “transparently” 
{e.g.,  type  set  =  int  list).  Signatures  that  support  both  kinds  of  specifications  are  known  as 
“translucent.” 

Figure  1.5  shows  the  signature  for  generic  sets  that  one  would  write  in  the  ML  style.  Instead 
of  making  the  item  type  a  parameter  of  the  SET  signature,  the  ML  approach  is  to  include  item  as 
an  abstract  type  component  in  the  signature.  In  other  words,  a  module  implementing  sets  carries 
the  type  of  items  along  with  it,  whatever  that  type  may  be,  thus  enabling  the  generic  interface  for 
sets  to  be  self-contained. 

Figure  1.6  shows  how  the  implementation  of  the  Set  functor  is  made  abstract.  The  item 
component  of  the  Item  argument  is  copied  into  the  body  of  the  functor;  the  body  is  then  sealed  with 
the  signature  SET  where  type  item  =  Item,  item,  which  is  shorthand  in  ML  for  the  signature 
formed  by  taking  the  abstract  SET  signature  and  making  the  item  component  transparently  equal 
to  Item.  item.  Thus,  the  signature  with  which  the  body  of  the  Set  functor  is  sealed  is  translucent — 
it  reveals  the  identity  of  the  item  type,  which  is  necessary  in  order  for  the  resulting  set  module  to 
be  of  any  use,  but  it  holds  the  identity  of  the  set  type  abstract. 

Translucency  subsumes  the  utility  of  parameterized  signatures,  but  it  is  useful  for  other  reasons 
as  well.  First,  it  allows  one  to  reveal  partial  information  about  the  identity  of  a  type.  For  instance, 
suppose  a  module  exports  a  type  t  which  is  defined  internally  to  be  int  *  string,  and  the  imple¬ 
mentor  of  the  module  wishes  to  reveal  that  values  of  type  t  are  pairs  whose  first  component  is  an 
integer,  but  does  not  wish  to  reveal  that  the  second  component  is  a  string.  Then  the  implementor 
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can  seal  the  module  with  a  signature  containing  an  opaque  type  u,  which  is  defined  internally  to 
be  string,  and  a  transparent  type  t  =  int  *  u. 

In  addition,  the  support  for  transparent  type  specifications  in  signatures  means  that  for  most 
modules  in  ML  there  is  a  principal  signature,  i.e.,  a  most-specific  signature  that  encapsulates  all  that 
can  be  observed  about  the  module  during  typechecking.  ^  For  example,  the  principal  signature  of  the 
module  Int  Item  dehned  in  Figure  1.4  is  COMPARABLE  where  type  item  =  int.  The  existence  of 
principal  signatures  is  advantageous  for  modular  program  development  because  it  allows  a  program 
to  be  divided  at  relatively  arbitrary  points,  with  the  assurance  that  all  the  typing  information  about 
any  one  component  of  the  program  is  expressible  in  the  form  of  a  signature  that  the  programmer 
can  write  independently  of  the  implementation  of  that  component. 

Lastly,  translucency  accounts  naturally  for  the  concept  of  type  sharing.  It  often  happens  that 
one  wants  to  take  as  input  to  a  functor  two  modules  (call  them  A  and  B),  each  of  which  provides  a 
type  component  t,  and  in  order  for  the  body  of  the  functor  to  make  any  sense  it  is  necessary  that 
A .  t  is  equal  to  B .  t.  ML  supports  such  a  “type  sharing”  constraint  by  letting  the  programmer  attach 
sharing  type  A.t  =  B.t  to  the  specification  of  the  functor  arguments.  In  earlier  versions  of  ML, 
such  as  SML  ’90,  type  sharing  constraints  provided  an  increase  in  expressive  power  that  proved 
difficult  to  account  for  in  type-theoretic  studies  of  the  module  system  [47,  29].  In  modern  dialects 
of  ML,  however,  type  sharing  can  be  seen  as  just  an  instance  of  translucency.  The  constraint 
sharing  type  A.t  =  B.t  can  be  seen  as  syntactic  sugar  that  has  the  effect  of  modifying  the 
signature  of  argument  B  so  that  its  type  component  t  is  specified  transparently  as  type  t  =  A.t.^ 

For  further  illustrations  of  the  power  of  translucent  signatures,  I  refer  the  reader  to  one  of  the 
more  pedagogical  treatments  of  ML  programming  that  are  available,  such  as  Harper  [26]. 


1.2  Key  Points  and  Axes  in  the  Design  Space  of  ML  Modules 

Since  its  inception  [46],  the  ML  module  system  has  been  associated  with  the  mechanisms  of  sig¬ 
natures,  structures  and  functors.  The  sealing  mechanism®  was  proposed  early  on  by  MacQueen 
in  the  form  of  an  abstraction  binding,  which  was  implemented  in  1993  in  an  early  version  of 
the  SML/NJ  compiler  (version  0.93)  [71].  Translucent  signatures  were  also  implemented  in  version 
0.93  of  SML/NJ,  but  were  not  treated  formally  until  1994,  when  Harper  and  Lillibridge  [28]  and 
Leroy  [42]  independently  proposed  similar  formalisms  for  them  at  the  same  POPL  symposium. 

Although  the  formal  accounts  prior  to  that  point  still  provide  much  valuable  insight — particularly 
Harper,  Mitchell  and  Moggi’s  work  on  higher-order  modules  [30],  which  introduces  the  concept  of 
phase  separation  that  underlies  much  of  the  analysis  in  Chapter  2  and  the  formal  system  in  Chap¬ 
ter  4 — I  am  focused  in  this  thesis  on  accounting  for  the  semantic  variations  among  the  “modern” 
variants  of  the  ML  module  system  that  support  all  of  the  features  described  in  Section  1.1,  includ¬ 
ing  translucency.  In  this  section  I  will  describe  several  such  variants  and  how  they  relate  to  one 
another  in  the  design  space  of  ML  modules.  I  will  begin,  though,  with  a  bit  of  historical  context. 

®As  we  will  see  in  Section  4.2.6,  due  to  the  “avoidance  problem,”  not  all  modules  in  ML  have  principal  signatures, 
but  there  is  a  considerable  snbset  of  ML  in  which  modnles  do  have  principal  signatnres.  Also,  to  avoid  confusion,  it 
is  worth  noting  that  the  Commentary  on  the  original  Definition  of  SML  [50]  also  uses  the  term  principal  signature, 
but  to  describe  a  concept  unrelated  to  the  notion  of  fully-descriptive  signatnre  intended  here. 

"^Or,  if  modnle  B  comes  before  A  in  the  order  of  the  functor  arguments,  modifying  the  signature  of  A  so  that  its 
type  component  t  is  specified  transparently  as  type  t  =  B.t.  For  details  on  how  type  sharing  constraints  may  be 
desugared  in  general,  see  Chapter  9. 

®I  mean  sealing  here  in  its  “opaque”  form  (:>),  as  described  in  Section  1.1.2.  In  contrast,  the  “transparent”  form 
of  sealing  ( : )  was  part  of  the  Definition  from  the  beginning,  but  does  not  provide  full  support  for  data  abstraction 
and  is  not  present  in  other  dialects  of  ML,  such  as  O’Caml.  For  further  discussion  of  the  difference  between  opaque 
and  transparent  sealing,  see  Section  9.3.2. 
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1.2.1  Precursors  to  Translucency 

The  idea  of  translucency  present  in  modern  variants  of  ML  arose  in  response  to  a  bifurcation  that 
had  developed  in  the  late  ’80s  and  early  ’90s  in  the  semantics  of  modularity.  On  one  hand  there 
was  the  approach  taken  by  SML  ’90  [51],  which  is  modeled  in  formal  accounts  by  MacQueen  [47] 
and  Harper  et  al.  [29,  30]  in  terms  of  “strong  sum”  types.  While  it  supports  client-side  data 
abstraction  via  functors,  SML  ’90  does  not  fully  support  implementor-side  data  abstraction.  In 
particular,  sealing  in  SML  ’90  is  “transparent,”  that  is,  sealing  a  module  with  a  signature  limits 
which  components  of  the  module  are  externally  visible  but  does  not  hide  the  definitions  of  any 
visible  type  components,  even  those  that  are  specified  opaquely  in  the  signature.  (Lillibridge 
correspondingly  termed  the  SML  ’90  approach  the  “transparent”  approach  to  modularity  [45].)  In 
addition,  as  I  have  already  mentioned,  the  type-theoretic  treatments  of  SML  ’90-style  modularity 
were  not  able  to  account  for  the  idea  of  type  sharing  constraints  in  signatures. 

On  the  other  hand  there  was  the  “opaque”  approach,  due  to  Mitchell  and  Plotkin  [53],  in 
which  abstract  data  types  are  modeled  as  existential  types.  Existentials  provide  an  elegant  logical 
foundation  for  type  abstraction  and,  unlike  the  transparent  approach,  provide  full  support  for 
implementor-side  data  abstraction.  They  are  awkward,  however,  as  a  basis  for  modular  program 
construction.  In  particular,  a  value  of  existential  type  is  not  as  flexible  as  an  ML  module.  One 
cannot  refer  to  the  abstract  types  and  associated  operations  provided  by  such  a  value  via  the 
standard  “dot  notation”  {e.g.,  IntSet .  insert)  used  for  modules.  Rather,  in  order  to  use  a  value 
V  of  type  da.C,  one  must  “open”  or  “unpack”  v — as  in  the  expression  “open  v  as  [a,x\  in  e” — in 
which  case  the  scope  of  the  abstract  type  a  and  of  the  associated  operations  represented  by  x  (of 
type  C)  is  limited  to  the  expression  e.  In  contrast,  unless  otherwise  delimited,  the  scope  of  the 
types  and  values  provided  by  an  ML  module  is  “the  rest  of  the  program,”  which  may  not  even  have 
been  written  yet.  Furthermore,  whereas  the  transparent  approach  suffers  from  allowing  too  much 
type  information  to  be  propagated,  the  opaque  approach  suffers  from  not  allowing  enough.  For 
example,  if  one  applies  the  identity  function  id  to  a  value  v  of  type  3a. C,  there  is  no  way  to  tell 
that  V  and  id{v)  share  their  abstract  type  component  because  there  is  no  way  to  even  refer  to  v’s 
abstract  type  component.  In  contrast,  applying  the  identity  functor  to  the  IntSet  module  in  ML 
(even  in  SML  ’90)  will  result  in  a  module  whose  set  type  is  transparently  equal  to  IntSet. set. 

As  illustrated  in  Section  1.1.3,  translucent  signatures  and  opaque  sealing  address  the  deficiencies 
of  both  the  opaque  and  the  transparent  approaches  to  modularity,  combining  the  flexibility  of 
ML-style  modules  with  the  support  for  implementor-side  abstraction  provided  by  existentials.® 
Although  Harper  and  Lillibridge  [28]  and  Leroy  [42]  differ  in  their  terminology,  the  former  speaking 
of  “translucent  sums”  and  the  latter  of  “manifest  types,”  the  basic  idea  of  translucency  put  forth 
by  both  papers  is  the  same.  The  key  point  that  distinguishes  these  two  accounts  is  that  Harper 
and  Lillibridge’s  supports  first-class  modules  whereas  Leroy’s  supports  second-class  modules. 

1.2.2  First-Class  vs.  Second-Class,  Higher-Order  vs.  First-Order 

The  primary  feature  that  distinguishes  functional  programming  languages  from  other  kinds  of 
languages  is  that  in  functional  languages  functions  are  treated  as  “first-class”  entities,  i.e.,  they 
may  be  produced  as  the  result  of  arbitrary  computations  and  stored  inside  data  structures,  just 
like  any  other  kind  of  data.  As  a  consequence  of  being  first-class,  functions  are  also  “higher-order,” 
i.e.,  they  can  take  functions  as  arguments  and  return  functions  as  results. 

Unlike  functions,  modules  are  not  treated  as  first-class  entities  in  most  dialects  of  the  ML  module 

®See  Chapters  2  and  3  of  Lillibridge’s  thesis  for  more  discussion  and  examples  of  this  [45]. 
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system.  They  are  “second-class”  in  the  sense  that  the  module  language  exists  on  a  separate  plane 
from  the  so-called  “core”  language  of  ML.  Modules  may  not  be  passed  as  arguments  to  or  results 
from  core-language  functions,  nor  can  they  be  stored  in  data  structures.  In  some  sense  this  is 
justihed  by  thinking  about  modules  as  primarily  serving  to  structure  code  in  a  pre-existing  core 
language. 

A  less  defensible  aspect  of  the  Standard  ML  module  system  in  particular — and  one  not  shared 
by  all  dialects  of  ML — is  that  functors  are  restricted  to  be  “first-order,”  meaning  that  they  may 
only  be  defined  at  the  top  level  of  the  program,  not  as  components  of  other  modules,  and  thus 
functors  cannot  be  parameterized  over  other  functors  or  return  other  functors  as  results.  It  is 
difficult  to  explain  why  functions  at  the  module  level  of  SML  are  restricted  in  a  way  that  functions 
at  the  core  level  are  not.  As  a  consequence,  whether  or  not  they  treat  modules  in  general  as  first-  or 
second-class,  most  modern  variants  of  ML — including  most  implementations  of  Standard  ML — do 
provide  support  for  higher-order  functors.  The  semantics  of  higher-order  functors,  however,  is  an 
axis  in  the  design  space  of  modules  along  which  we  will  find  considerable  variety. 

1.2.3  Harper  and  Lillibridge’s  First-Class  Modules 

Harper  and  Lillibridge’s  “translucent  sums”  calculus  does  not  distinguish  the  language  of  modules 
from  the  core  language  of  terms,  thus  treating  modules  as  first-class  values.  The  fusion  of  the 
module  and  term  levels  leads  to  a  pleasantly  economical  design,  in  which  structures  are  merely 
records,  and  functors  are  merely  functions.  In  addition,  the  first-class  status  of  modules  allows 
one  to  choose  between  different  implementations  of  an  abstract  data  type  at  run  time  based  on 
information  that  may  only  be  available  dynamically. 

To  steal  an  example  from  Lillibridge’s  thesis  [45],  suppose  one  is  dehning  a  module  implementing 
dictionaries.  Depending  on  the  size  of  the  dictionaries  that  one  will  be  creating,  one  may  wish  to  use 
different  implementations.  For  large  dictionaries,  a  hash  table  implementation  may  be  appropriate, 
but  for  small  ones,  a  linked  list  implementation  will  be  more  space-efficient.  If  the  size  is  not  known 
statically,  first-class  modules  enable  one  to  make  this  choice  at  run  time  by  defining  the  dictionary 
module  with  a  conditional  expression: 

structure  Dictionary  =  if  n  <  20  then  LinkedList  else  HashTable 

At  the  same  time,  however,  merging  the  core  and  module  levels  also  complicates  the  type 
structure  of  the  core  language,  interfusing  it  with  notions  of  dependent  types  and  subtyping.  As  a 
result,  typechecking  in  the  Harper-Lillibridge  system  is  proven  undecidable,  and  moreover  it  is  not 
clear  how  ML-style  type  inference  could  be  adapted  to  it.  For  the  moment,  though,  I  will  ignore 
the  more  practical  problems  with  the  Harper-Lillibridge  approach,  in  favor  of  exposing  a  lack  of 
expressiveness  with  respect  to  higher-order  functors. 

Since  functors  are  just  functions  in  the  Harper-Lillibridge  system,  they  are  naturally  higher- 
order.  Consider,  however,  a  simple  canonical  example  of  a  higher-order  functor,  namely  the  Apply 
functor  shown  in  Figure  1.7.  Apply  takes  a  functor  argument  F  of  signature  SIG  ->  SIG  and  a 
structure  argument  X  of  signature  SIG — where  SIG  is  a  signature  with  an  opaque  specihcation  of 
some  type  t — and  it  applies  F  to  X.  Ideally,  Apply  (F)  (X)  should  be  semantically  indistinguishable 
from  F(X).  Unfortunately,  this  turns  out  not  to  be  the  case. 

First  of  all,  what  is  the  type  (i.e.,  signature)  of  Apply?  The  obvious  answer — and  the  one 
given  in  Harper  and  Lillibridge’s  system — is  (SIG  ->  SIG)  ->  (SIG  ->  SIG).  Given  this  type,  if 
we  instantiate  Apply  with  any  arguments  of  the  appropriate  types,  regardless  of  what  they  are,  we 
get  out  a  structure  of  signature  SIG.  In  particular,  if  we  apply  Apply  to  the  identity  functor  Ident, 
also  defined  in  Figure  1.7,  and  a  particular  structure  Arg  of  type  SIG,  then  the  result  Resl  has  type 
SIG  as  well,  giving  us  no  indication  that  its  type  component  t  is  in  fact  equal  to  Arg.t. 
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signature  SIG  =  sig  type  t  ...  end 

functor  Apply  (F  :  SIG  ->  SIG)  (X  :  SIG)  =  F(X) 
functor  Ident  (X  :  SIG)  =  X 


structure 
(*  Resl.t 
structure 
(*  Res2.t 


Resl  =  Apply(Ident) (Arg) 
/  Arg.t  *) 

Res2  =  Ident (Arg) 

=  Arg.t  *) 


Figure  1.7:  Higher-Order  Functor  Example 


On  the  other  hand,  consider  what  happens  when  we  apply  Ident  to  Arg  directly  and  bind 
the  result  to  Res2.  Although  Ident  does  indeed  match  the  type  SIG  ->  SIG,  its  principal  type  is 
(X:SIG)  ->  (SIG  where  type  t  =  X.t).  (This  is  a  dependent  function  type,  where  the  argument 
X  is  bound  in  the  right-hand  side  of  the  arrow.)  Thus,  substituting  Arg  for  X,  we  see  that  the  type 
of  Res2  is  SIG  where  type  t  =  Arg.t,  from  which  we  can  infer  that  Res2.t  =  Arg.t.  In  order 
to  observe  this  equivalence  for  Resl,  we  would  need  to  require  that  Apply’s  functor  argument  have 
the  more  specific  type  of  Ident,  but  that  would  in  turn  place  a  rather  arbitrary  restriction  on  the 
potential  arguments  to  Apply. 

1.2.4  SML/NJ’s  Higher-Order  Functors 

One  approach  to  remedying  this  problem  was  proposed  by  MacQueen  and  Tofte  [49]  and  incor¬ 
porated  into  the  SML/NJ  compiler.  Their  solution  is  to  “re-typecheck”  the  body  of  the  Apply 
functor  at  every  application  site,  exploiting  knowledge  of  Apply’s  actual  arguments  to  propagate 
more  type  information.  Thus,  under  their  semantics,  typechecking  the  Resl  module  in  Figure  1.7 
prompts  a  re- typechecking  of  Apply  given  the  knowledge  that  F  in  this  instance  has  a  more  specific 
type,  namely  the  principal  type  of  Ident.  Given  this  added  information,  the  typechecker  can  then 
observe  that  Resl.t  =  Arg.t.^ 

MacQueen  and  Tofte  essentially  argue  that  since  Mb’s  signature  language  is  too  weak  to  express 
the  dependency  between  the  result  of  Apply  and  its  argument,  one  must  inspect  the  implementation 
instead.  This  is  a  sensible  argument  when  one  has  access  to  Apply’s  implementation.  In  the 
context  of  separate  compilation,  however,  it  is  inapplicable,  as  Apply’s  implementation  may  not 
be  available.  Moreover,  the  MacQueen- Tofte  solution  is  fundamentally  non-type-theoretic,  in  the 
sense  that  signatures  in  their  language  do  not  encapsulate  the  information  about  a  higher-order 
functor  that  may  be  needed  during  typechecking.®  As  I  am  ultimately  concerned  with  developing 
an  account  of  ML  modules  that  can  be  formalized  in  type  theory  and  that  makes  sense  in  the 
presence  of  separate  compilation,  I  will  focus  attention  in  this  thesis  on  the  following  alternative 
approach  to  higher-order  functors. 


practice,  the  SML/NJ  compiler  does  not  actually  re-typecheck  the  body  of  a  higher-order  functor  every  time 
it  is  applied.  Rather,  it  employs  an  implementation  technique  that  mimics  re-typechecking  without  actually  doing 
it.  This  technique,  described  by  Cregut  and  MacQueen  [7],  produces  a  static  representation  for  each  functor  that 
contains  all  information  concerning  the  “compile-time  behavior”  of  the  functor. 

®In  the  SML/NJ  implementation,  the  static  representation  of  a  functor  (described  in  the  previous  footnote) 
doe.s  encapsulate  all  information  needed  about  it  during  typechecking.  However,  this  static  representation  may  not 
correspond  to  any  signature  that  the  ML  programmer  can  write.  Furthermore,  Cregut  and  MacQueen  do  not  provide 
any  formal  semantics  for  it  [7]. 
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1.2.5  Leroy’s  Applicative  Functors 

Leroy’s  “manifest  types”  calculus,  while  second-class,  suffers  from  the  same  problem  as  Harper 
and  Lillibridge’s  with  respect  to  poor  propagation  of  type  information  in  higher-order  functors 
like  Apply.  In  a  follow-up  paper  the  following  year,  however,  Leroy  [43]  presents  a  solution  to  the 
problem  that  is  quite  different  from  SML/NJ’s.  He  proposes  an  “applicative”  semantics  for  functors 
as  an  alternative  to  Standard  ML’s  “generative”  semantics. 

Functors  in  SML,  as  well  as  in  the  translucent  sum  and  manifest  type  calculi,  behave  “genera- 
tively,”  in  the  sense  that  every  time  a  functor  is  applied  it  generates  fresh  abstract  types.  In  other 
words,  if  a  functor  F  is  applied  to  the  same  argument  twice,  and  the  results  are  bound  to  A  and  B, 
then  A.t  and  B.t  will  be  considered  distinct  for  any  type  component  t  that  is  specified  opaquely 
in  the  result  signature  of  F.  For  example,  since  the  argument  F  of  the  Apply  functor  has  signature 
SIG  ->  SIG,  the  application  of  F  in  the  body  of  Apply  results  in  a  module  with  a  fresh  abstract 
type  t.  According  to  this  generative  semantics,  it  makes  sense  that  Resl  .t  is  distinct  from  Arg.t, 
because  every  application  of  Apply  produces  a  new  type  t,  distinct  from  all  others.  Nevertheless, 
as  I  have  argued,  this  is  not  the  desired  behavior  for  the  Apply  functor. 

Leroy  proposes  instead  that,  when  a  functor  is  applied  to  the  same  argument  module  more 
than  once,  it  should  produce  the  same  abstract  types  in  each  result  module.  In  order  to  realize 
this  “applicative”  semantics  for  functors,  Leroy  extends  the  dot  notation  so  that,  in  addition  to 
projecting  types  from  named  structures,  one  can  project  types  from  functor  applications. 

For  example,  given  that  F  has  signature  SIG  ->  SIG,  the  principal  signature  for  F(X)  in  Leroy’s 
applicative  functor  calculus  is  SIG  where  type  t  =  F(X)  .t,  which  indicates  that  the  type  t  in 
the  result  of  Apply  is  precisely  the  one  obtained  by  applying  F  to  X.  Thus,  substituting  Ident  for 
F  and  Arg  for  X,  we  see  that  Resl  (defined  as  Apply  (Ident)  (Arg))  can  under  Leroy’s  semantics 
be  given  the  signature  SIG  where  type  t  =  Ident  (Arg)  .t.  The  signature  of  Ident  allows  us,  in 
turn,  to  observe  that  Ident  (Arg)  .t  =  Arg.t,  so  that  Resl.t  =  Arg.t  as  desired. 

It  is  natural  to  ask  whether  Leroy’s  solution  carries  over  to  the  setting  of  a  first-class  module 
system  like  Harper  and  Lillibridge’s.  The  answer  is  that  it  does  not,  and  the  reason  is  that  in  a 
hrst-class  module  system  it  does  not  in  general  make  sense  to  write  a  type  like  F  (X)  .  t.  For  instance, 
in  the  Harper-Lillibridge  system,  a  functor  of  signature  SIG  ->  SIG,  when  applied,  may  very  well 
consult  some  dynamically  changing  condition — e.g.,  whether  a  mouse  button  is  pressed — and  the 
identity  of  the  type  components  in  the  module  it  returns  may  depend  on  that  condition.  Thus,  one 
evaluation  of  F(X)  may  result  in  a  module  whose  t  component  is  defined  to  be  int  and  another 
may  result  in  one  whose  t  component  is  dehned  to  be  string.  Since  the  evaluation  of  F(X)  does 
not  always  produce  the  same  t  component,  it  is  senseless  to  refer  to  the  type  F(X)  .t. 

This  is  not  an  issue,  however,  for  a  second-class  system  like  Leroy’s,  which  obeys  the  principle  of 
phase  separation.  A  module  system  obeying  phase  separation  is  one  in  which  every  module  can  be 
split  into  a  static  part  (comprising  its  type  components)  and  a  dynamic  part  (comprising  its  term 
components),  such  that  the  static  part  does  not  depend  on  the  dynamic  part.  In  such  a  system,  the 
type  components  of  modules  cannot  depend  on  any  dynamic  conditions — they  are  the  same  every 
time  the  module  is  evaluated.  Phase  separation  is  ensured  in  the  case  of  Leroy’s  system  by  the 
restricted  “second-class”  nature  of  the  language  in  which  modules  are  written.  A  consequence  of 
phase  separation  is  that  it  makes  sense  to  talk  about  the  type  F  (X)  .  t  because  the  type  components 
of  F(X)  are  guaranteed  to  be  the  same  every  time  it  is  evaluated. 

Although  Leroy’s  calculus,  which  serves  as  the  basis  of  the  Objective  Caml  module  system,  has 
succeeded  in  popularizing  the  idea  of  applicative  functors,  both  the  concepts  of  phase  separation 
and  applicative  functor  semantics  were  actually  introduced  in  earlier  work  by  Harper,  Mitchell  and 
Moggi  [30].  While  their  calculus  admittedly  lacks  any  account  of  sealing  or  translucency,  it  has 
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signature  SYMBOL_TABLE  = 
sig 

type  symbol 

val  string2symbol  :  string  ->  symbol 
val  symbol2string  :  symbol  ->  string 

end 

functor  SymbolTable  ()  = 
struct 

type  symbol  =  int 

val  table  :  HashTable.t  = 

(*  allocate  internal  hash  table  *) 
Hash! able .  create  (initial  size,  NONE) 
fun  string2symbol  x  = 

(*  lookup  (or  insert)  x  *)  ... 
fun  symbol2string  n  = 

(case  Hash! able . lookup  (table,  n)  of 
SOME  X  =>  X 

I  NONE  =>  raise  (Fail  "bad  symbol")) 


end 

:>  SYMBOL. TABLE 

structure  STl  =  SymbolTable () 
structure  ST2  =  SymbolTable () 

Figure  1.8;  Symbol  Table  Functor  Example 


been  a  strong  influence  on  other  module  languages,  not  least  on  the  design  of  my  own  type  system 
for  modules.  I  will  discuss  their  calculus’  relationship  to  mine  in  more  detail  in  Section  2.2.3. 

1.2.6  The  Importance  of  Generativity 

The  discussion  so  far  might  lead  one  to  the  conclusion  that  the  applicative  semantics  for  functors  is  a 
clear  improvement  over  the  generative  semantics,  but  this  is  not  the  case — the  two  are  incomparable. 
As  we  have  seen,  the  applicative  semantics  allows  for  the  desired  propagation  of  type  information  in 
higher-order  functors.  For  other  kinds  of  functors,  however,  generativity  is  essential  for  guaranteeing 
the  desired  degree  of  data  abstraction. 

Consider,  for  example,  the  SymbolTable  functor  shown  in  Figure  1.8,  which  takes  no  arguments 
but,  when  applied,  generates  a  module  implementing  a  symbol  table  as  a  hash  table.  The  module 
represents  symbols  as  integer  indices  into  the  hash  table,  and  thus  defines  the  symbol  type  to  be 
int.  It  defines  the  hash  table  itself  by  invoking  the  create  function  from  the  standard  library 
HashTable  module  and  binding  the  result  to  table.  It  then  defines  two  functions  for  converting 
between  strings  and  symbols:  string2symbol,  which  inserts  a  string  into  the  table  and  returns  the 
corresponding  symbol,  and  symbol2string,  which  looks  up  a  symbol  in  the  table  and  returns  the 
corresponding  string.  The  latter  function  raises  a  Fail  exception  if  the  given  symbol  is  invalid. 
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Finally,  the  body  of  the  SymbolTable  functor  is  sealed  with  the  SYMBOL_TABLE  signature.  The 
sealing  serves  two  purposes.  One  is  to  prevent  the  actual  table  from  being  exported,  so  that  the 
implementation  in  terms  of  a  hash  table  is  not  revealed.  The  other  is  to  prevent  the  clients  of  the 
functor  from  being  able  to  observe  that  symbol  is  equal  to  int  and  attempting  to  pass  off  arbitrary 
integers  as  valid  indices  into  the  hash  table. 

The  intention  of  this  implementation  is  that  the  Fail  exception  should  never  be  raised  because 
the  only  values  of  type  symbol  that  clients  should  ever  have  access  to  are  those  obtained  through 
calls  to  string2symbol,  which  are  clearly  valid  symbols.  Under  an  applicative  functor  semantics, 
however,  this  intention  will  not  be  upheld.  Specifically,  suppose  that  structures  STl  and  ST2 
are  both  defined  by  calls  to  SymbolTable,  as  shown  in  Figure  1.8.  According  to  the  applicative 
semantics,  STl.  symbol  =  ST2.  symbol  because  both  types  are  equal  to  SymbolTable  ()  .symbol. 
As  a  result,  symbols  generated  by  calls  to  STl .  string2symbol  may  be  passed  as  arguments  to 
ST2 .  symbol2string,  even  though  such  symbols  are  not  necessarily  valid  indices  into  ST2’s  hash 
table  and  may  cause  its  symbol2string  function  to  raise  the  Fail  exception.  Therefore,  although 
it  is  perfectly  sound  to  consider  the  SymbolTable  functor  applicative,  the  functor  ought  to  be 
considered  generative.  Every  symbol  type  it  produces  classifies  valid  indices  into  a  newly  generated 
symbol  table  and  is  thus  semantically  incompatible  with  every  other  symbol  type. 

On  the  other  hand,  for  a  functor  like  the  Set  functor  defined  in  Figure  1.6,  the  applicative  seman¬ 
tics  is  perfectly  appropriate.  Suppose  we  apply  Set  to  the  same  item  module — e.g.,  Intitem — twice 
and  bind  the  results  to  IntSetl  and  IntSet2.  The  types  IntSetl .  set  and  IntSet2 .  set  both  de¬ 
scribe  sets  of  integers  ordered  according  to  the  same  Intitem.  compare  function,  so  there  is  no 
reason  to  distinguish  them. 

1.2.7  Supporting  Both  Applicative  and  Generative  Functors 

Each  of  the  major  dialects  of  ML,  SML  and  O’Caml,  supports  only  one  semantics  for  functors: 
generative  or  applicative,  but  not  both.  The  analysis  above,  however,  suggests  that  since  each 
semantics  is  appropriate  in  different  circumstances,  it  would  be  preferable  to  have  a  module  language 
that  does  support  both. 

The  module  system  of  the  Moscow  ML  dialect  [56],  based  to  a  large  extent  on  Russo’s  thesis 
work  [65],  represents  one  such  hybrid  design.  In  Moscow  ML,  the  programmer  can  choose,  when 
defining  a  functor,  whether  it  should  behave  applicatively  or  generatively.  While  the  simplicity  of 
this  approach  is  appealing,  it  is  semantically  problematic.  In  particular,  one  would  expect  that 
every  application  of  a  generative  functor  produces  distinct  abstract  types,  but  this  is  not  the  case. 
For  example,  if  one  were  to  define  the  SymbolTable  functor  from  Figure  1.8  in  Moscow  ML  and  label 
it  generative,  there  would  be  nothing  to  prevent  one  from  defining  another  functor  SymbolTable  ’  as 
the  eta-expansion  of  SymbolTable — i.e.,  functor  SymbolTable’  ()  =  SymbolTable () — and  then 
labeling  SymbolTable’  as  applicative.  Consequently,  different  instances  of  SymbolTable’  would  be 
considered  to  have  equivalent  symbol  types,  even  though  “under  the  hood”  they  are  really  different 
instances  of  SymbolTable,  which  according  to  generativity  should  have  distinct  symbol  types.  What 
is  even  more  troublesome  is  that  the  ability  to  subvert  the  generativity  of  SymbolTable  in  this  way 
can  be  further  exploited  to  break  the  soundness  of  the  type  system  [9]. 

The  problems  with  Moscow  ML  suggest  that  in  order  to  guarantee  that  generativity  is  respected 
by  the  type  system,  one  must  restrict  the  class  of  functors  that  may  behave  applicatively.  This  is 
precisely  what  Shao  does  in  his  type  system  for  ML-style  modules  [69].  Like  Moscow  ML,  Shao’s 
calculus  supports  both  applicative  and  generative  functors.  The  key  idea  in  Shao’s  system  is  to  only 
allow  functors  to  be  treated  as  applicative  if  their  bodies  are  transparent.  (Correspondingly,  Shao 
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refers  to  applicative  functors  as  “transparent”  and  generative  functors  as  “opaque.”)  As  a  result, 
the  eta-expansion  of  SymbolTable  from  the  previous  paragraph  could  not  be  labeled  as  applicative 
in  Shao’s  system  because  the  principal  signature  of  its  body  is  SYMBOL _TABLE,  which  specifies  the 
symbol  type  opaquely. 

Although  Shao’s  approach  ensures  that  generativity  is  respected,  I  argue  that  it  is  overly  re¬ 
strictive.  For  example,  the  Set  functor  from  Figure  1.6  could  not  be  treated  as  applicative  in  Shao’s 
system,  at  least  not  as  written,  because  its  body  is  sealed  with  an  abstract  interface.  In  the  case 
of  our  implementation  of  sets  as  lists,  we  can  work  around  this  problem  by  hoisting  the  sealing 
outside  of  the  functor.  In  other  words,  we  can  leave  the  body  of  the  functor  alone  and  instead  seal 
the  functor  itself  with  the  signature 

(Item  :  COMPARABLE)  ->  SET  where  type  item  =  Item. item 

Since  the  sealing  no  longer  occurs  inside  the  functor  body,  the  body  has  a  transparent  signature, 
and  thus  Shao’s  system  will  treat  the  functor  as  applicative. 

However,  this  technique  does  not  always  apply.  For  instance,  suppose  that  we  define  a  new 
functor  implementation  of  sets.  Set  ’ ,  in  which  the  set  type  is  defined  by  an  ML  datatype  dec¬ 
laration  instead  of  as  an  abbreviation  for  item  list.  Types  defined  by  datatype  declarations  in 
ML  are  abstract  and  distinct  from  all  other  types.  Therefore,  even  without  explicitly  sealing  it,  the 
body  of  the  Set’  functor  will  contain  an  opaque  set  type,  and  Shao’s  type  system  will  treat  Set’ 
as  generative.  Semantically  speaking,  however,  there  is  no  reason  why  Set  ’  should  not  behave 
applicatively,  since  repeated  application  of  Set  ’  to  the  same  item  module  produces  modules  with 
perfectly  compatible  set  types. 

To  summarize,  whereas  Moscow  ML  allows  one  to  write  too  many  applicative  functors,  Shao’s 
language  allows  one  to  write  too  few. 

1.2.8  Notions  of  Module  Equivalence 

In  the  above  discussion,  I  have  defined  applicative  semantics  of  functors  informally  by  saying  that 
a  functor  behaves  applicatively  if,  when  applied  to  the  same  module  twice,  it  produces  results  with 
equivalent  type  components.  I  have  implicitly  taken  for  granted  in  this  definition  that  “the  same 
module”  has  some  agreed-upon  meaning.  In  fact,  however,  the  manner  in  which  equivalence  of 
modules  is  defined  is  yet  another  axis  along  which  several  variants  of  the  ML  module  system  differ. 

In  Leroy’s  applicative  functor  calculus  (and  hence  in  O’Caml),  module  equivalence  is  syntactic: 
two  modules  are  equivalent  only  if  they  have  the  same  name.  For  example,  module  X  is  equivalent  to 
itself  but  not  to  any  other  module  Y,  even  if  Y  is  defined  by  the  module  binding  structure  Y  =  X. 
Consequently,  supposing  that  functor  F  returns  an  opaque  type  t  in  its  result,  then  F(X)  .t  is 
equivalent  to  itself,  but  not  to  F(Y)  .t.  This  is  unfortunate,  as  bindings  like  structure  Y  =  X  are 
commonly  used  in  ML  programming  in  order  to  give  an  abbreviated  name  to  a  module  that  will 
be  frequently  referred  to.  Distinguishing  between  a  module  name  and  its  abbreviation,  based  not 
on  any  semantic  distinction  but  on  a  purely  syntactic  consideration,  makes  for  a  somewhat  brittle 
semantics.® 

Connected  to  Leroy’s  syntactic  characterization  of  module  equivalence  is  his  requirement  that 
functor  applications  appearing  inside  types  be  in  “named  form.”  For  example,  F(X)  .t  is  a  well- 
formed  type,  but  F (struct  .  .  .  end)  .t  is  not.  This  named  form  restriction  is  useful  in  order  to 
avoid  having  the  well-formedness  of  a  program  depend  on  the  syntactic  equivalence  of  arbitrary 
module  expressions,  which  is  a  rather  fragile  property. 

®See  Section  4.2.6  for  another  example  of  peculiar  behavior  due  to  the  syntactic  nature  of  O’Caml  typechecking. 
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A  consequence  of  the  restriction,  however,  is  that  there  are  some  higher-order  functors  which 
cannot  be  given  fully  expressive  signatures  in  O’Caml.  For  instance,  to  take  an  example  from 
Leroy  [43],  suppose  we  tweak  the  Apply  functor  so  that  instead  of  returning  F(X),  it  returns 
F (struct  type  t  =  X.t  *  X.t;  val  x  =  (X.x,X.x)  end).  Due  to  the  named  form  restriction, 
the  best  result  signature  we  can  give  to  this  version  of  the  Apply  functor  is  the  opaque  SIG,  which 
is  precisely  how  the  functor  body  would  be  classified  in  the  absence  of  applicative  functors.  Thus, 
in  some  cases  at  least,  the  named  form  restriction  defeats  the  purpose  of  introducing  applicative 
functors  in  the  first  place. 

An  approach  several  people  have  suggested  for  remedying  this  problem  is  to  abandon  the  named 
form  restriction  and  employ  a  more  semantic  definition  of  module  equivalence.  But  which  definition 
is  best?  One  is  full  observational  equivalence,  or  some  conservative  approximation  thereof,  but  such 
a  definition  complicates  the  type  structure  significantly  by  making  type  equivalence  depend  on  a 
notion  of  term  equivalence.  An  alternative,  which  is  employed  by  Shao  [69],  Russo  [65],  and  Harper, 
Mitchell  and  Moggi  [30]  in  their  respective  module  languages,  is  to  treat  module  equivalence  as 
purely  “static,”  meaning  that  it  only  looks  at  the  type  components  of  modules,  not  their  value 
components,  and  thus  deems  two  modules  equivalent  if  their  type  components  are  equivalent.^® 

Static  module  equivalence  is  sensible  in  the  presence  of  phase  separation,  discussed  above  in 
Section  1.2.5.  If  modules  obey  phase  separation,  then  the  identity  of  a  type  of  the  form  F(M)  .t, 
even  where  M  is  an  arbitrary  module  expression  (such  as  struct  .  .  .  end),  depends  only  on  the 
static  parts  of  F  and  M.  As  the  static  part  of  F  is  clearly  equivalent  to  itself,  the  equivalence 
of  F(M)  .t  and  F(N)  .t  may  be  decided  just  by  looking  at  the  static  parts  of  M  and  N,  i.e.,  by 
comparing  M  and  N  according  to  a  notion  of  static  module  equivalence. 

In  addition  to  avoiding  the  need  for  truly  dependent  types,  static  module  equivalence  is  the 
most  liberal  notion  of  module  equivalence  that  is  still  sound.  While  Shao  and  Russo  both  take  it 
as  axiomatic  that  this  implies  that  static  module  equivalence  is  the  “right”  notion,  I  would  argue 
that  this  is  not  necessarily  the  case.  For  an  example,  let  us  return  once  again  to  our  trusty  Set 
functor.  Say  that  we  apply  Set  to  two  different  item  modules,  which  both  define  the  type  item 
to  be  int,  but  which  provide  different  integer  comparison  functions.  According  to  static  module 
equivalence,  the  set  types  in  the  resulting  modules  should  be  equivalent,  because  they  result  from 
applying  the  same  Set  functor  to  modules  whose  type  components  are  equivalent.  In  fact,  however, 
the  resulting  set  types  are  not  compatible  because  they  describe  sets  ordered  in  different  ways. 
Sets  constructed  from  one  module  will  not  necessarily  meet  the  representation  invariants  assumed 
by  the  operations  of  the  other  module.  Thus,  treating  the  two  set  types  as  equivalent  is  clearly, 
in  some  sense,  a  violation  of  data  abstraction.  It  is  not  a  complete  violation  of  data  abstraction, 
though,  because  the  implementation  of  sets  as  lists  remains  hidden  to  clients  of  the  Set  functor. 
So  what  kind  of  violation  is  it?  One  of  the  key  contributions  of  the  following  chapter  is  to  give  a 
clear  and  satisfying  answer  to  this  question. 

1.2.9  Conclusion 

The  goal  of  this  section  has  been  to  give  the  reader  a  sense  of  the  key  questions  that  arise  in  the 
design  of  the  ML  module  system,  as  well  as  some  of  the  answers  that  have  been  proposed.  If  the 
debates  about  first-class  vs.  second-class  modules,  applicative  vs.  generative  functor  semantics,  and 
syntactic  vs.  static  module  equivalence  leave  one’s  head  spinning  with  tradeoffs,  that  is  a  completely 
natural  response  to  the  diverse,  fragmented  state  of  the  module  system  literature.  The  next  chapter 
should  hopefully  provide  an  antidote. 


^°The  manner  in  which  one  extracts  the  “type  components”  of  arbitrary  module  expressions  (including  functors) 
is  called  “phase-splitting”  and  will  be  made  precise  in  Chapter  4. 


Chapter  2 


A  Unifying  Account  of  ML  Modules 


The  previous  chapter  gave  a  brief  survey  of  several  concepts  that  stand  as  key  points  of  contention 
in  the  design  of  the  ML  module  system,  including  applicative  functors,  generativity,  and  first-class 
modules.  In  this  chapter  I  will  go  deeper,  in  an  attempt  to  understand  from  first  principles  how 
the  data  abstraction  afforded  by  the  ML  module  system  actually  works.  This  analysis  will  produce 
a  unifying  account  of  ML  modules  within  which  the  differences  between  existing  dialects  can  be 
more  coherently  understood.  This  account  will  then  guide  the  design  of  my  type  system  for  ML 
modules,  which  I  describe  at  a  high  level  in  Section  2.2  and  more  formally  in  Chapters  3  and  4. 

2.1  An  Analysis  of  ML-Style  Modularity 

As  illustrated  in  a  number  of  examples  from  Chapter  1,  a  central  feature  of  ML  modules  that 
distinguishes  them  from  modularity  mechanisms  in  most  other  languages  is  that  they  contain 
type  components.  Each  type  component  of  a  module  may  be  exported  either  with  or  without  its 
definition  (that  is,  “opaquely”  or  “transparently”).  Furthermore,  the  type  components  of  a  module 
may  be  projected  out  from  it  in  order  to  form  type  expressions  such  as  IntSet .  set. 

The  analysis  in  this  section  is  centered  around  the  following  simple  question: 

From  which  modules  should  one  be  allowed  to  project  out  the  type  components? 

As  we  have  already  seen,  this  is  a  question  to  which  different  variants  of  the  ML  module  system  give 
different  answers.  Standard  ML,  for  instance,  restricts  the  answer  to  modules  that  are  in  named 
form  {e.g.,  A.B.C),  whereas  O’Caml  extends  SML’s  answer  to  include  functor  applications  whose 
constituent  expressions  are  in  named  form,  like  Set  (Intitem) .  Shao  and  Russo  extend  this  further 
to  allow  projections  from  general  module  expressions  such  as  Set  (struct  .  .  .  end). 

The  question  is  one  that  arises  naturally  in  the  design  of  a  module  system.  It  is  typically 
addressed,  however,  not  in  its  own  right,  but  only  insofar  as  is  necessary  in  order  to  bolster  other 
design  decisions,  such  as  whether  the  module  language  is  to  support  applicative  or  generative 
semantics  for  functors  or  whether  it  is  to  treat  modules  as  first-  or  second-class.  In  this  section  I 
will  attempt  instead  to  broach  the  question  directly,  independent  of  any  particular  design  goals,  in 
the  hope  of  achieving  a  more  general,  more  satisfying  answer. 

2.1.1  Projectibility  and  Purity 

Let  us  say  that  a  module  expression  is  considered  “projectible”  if  one  is  permitted  to  project  out  its 
type  components  in  order  to  form  types.  Projectibility  is  not  an  absolute  condition;  in  designing  our 
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structure  X  =  M 
structure  Y  =  M 


M  is  projectible  X.t  =  M.t  =  Y.t 
Figure  2.1;  Scenario  Illustrating  Consequences  of  Projectibility 


module  language  we  may  define  it  as  we  like.  The  goal  here  is  to  understand  what  considerations 
should  inform  our  definition. 

To  begin  with,  is  there  any  reason  not  to  allow  all  modules  to  be  treated  as  projectible?  Well, 
if  the  type  M .  t  is  to  have  any  meaning  in  a  call-by-value  language,  then  it  is  “the  type  bound  to 
t  in  the  module  value  resulting  from  evaluating  M.”  Since  type  equivalence  is  reflexive,  it  can  only 
make  sense  to  write  M .  t  if  we  are  sure  that  every  time  we  evaluate  M  we  will  in  fact  get  the  same 
type  component  t  in  the  result,  i.e.,  if  we  are  sure  that  M.t  is  really  equal  to  M.t.  At  least  in  the 
context  of  a  first-class  module  language,  not  every  module  expression  M  has  this  property.  ^ 

For  example,  consider  the  following  modified  version  of  the  first-class  module  example  from 
Section  1.2.3: 


if  buttonIsSelectedO  then  LinkedList  else  HashTable  (Mgui) 

This  expression  checks  whether  a  button  in  a  GUI  has  been  selected  and,  based  on  that  information, 
returns  one  module  implementing  dictionaries  or  another.  Assume  both  LinkedList  and  HashTable 
export  some  type — let’s  call  it  t — that  will  serve  as  the  type  of  dictionaries,  and  assume  as  well 
that  each  module  implements  this  type  differently.  The  type  Mqui  •  t  does  not  make  any  sense. 
One  evaluation  of  Mgui  may  occur  at  a  time  when  the  button  in  the  GUI  is  selected  and  may  thus 
produce  LinkedList,  while  another  evaluation  may  occur  at  a  time  when  the  button  in  the  GUI 
is  not  selected,  resulting  in  HashTable.  As  these  module  values  have  different  bindings  for  t,  the 
type  Mgui  •  t  is  not  well-defined. 

So  we  see  that  there  are  certain  module  expressions  like  Mgui  that  it  does  not  make  sense  to  treat 
as  projectible.  Why  is  this  interesting?  Because,  for  modules  that  can  be  considered  projectible, 
more  propagation  of  type  information  is  possible.  In  particular,  consider  the  programming  scenario 
shown  in  Figure  2.1,  which  plays  such  an  important,  recurring  role  in  my  analysis  that  I  present  it 
here  in  a  somewhat  generic  form.  In  this  scenario,  there  are  two  module  variables  X  and  Y  that  are 
defined  in  separate  places  in  a  program  by  the  same  module  expression  M,  which  provides  a  type 
component  t.  The  point  of  this  scenario  is  the  following:  In  a  call-by- value  language  like  ML,  the 
module  variables  X  and  Y  will  be  bound  to  the  module  value  resulting  from  the  evaluation  of  M.  If 
M  is  a  projectible  expression,  then  every  time  it  is  evaluated  we  can  be  assured  that  the  resulting 
module  value  contains  the  same  binding  for  the  t  component,  and  thus  the  types  X.t  and  Y.t  can 
be  considered  equivalent  because  they  are  both  equal  (by  definition)  to  M.t.  Conversely,  if  we 
were  to  substitute  the  non-projectible  module  expression  Mgui  (defined  above)  in  place  of  M,  then 
it  would  be  unsound  to  treat  X .  t  and  Y .  t  as  equivalent  types. 

^It  should  be  understood  that  M  here  is  not  necessarily  a  module  variable/name  like  IntSet,  but  may  stand  for 
any  expression  in  the  language  of  modules,  examples  of  which  we  will  see  shortly.  The  distinction  between  module 
variables  and  arbitrary  module  expressions  will  be  denoted  by  writing  the  former  in  typewriter  font  and  representing 
the  latter  with  metavariables  like  M  written  in  roman  font. 
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In  general,  how  can  we  decide  whether  it  is  sound  to  consider  a  module  expression  M  projectible? 
One  approach  is  to  require  that  M  be  “pure,”  i.e.,  free  of  all  computational  effects,  in  which  case 
each  evaluation  of  M  should  in  fact  compute  the  same  module  value.  The  module  expression  Mgui 
is  not  pure  because,  each  time  it  is  evaluated,  it  consults  the  state  of  the  GUI;  like  dereferencing  a 
pointer  to  a  mutable  memory  cell,  this  constitutes  an  effectful  operation. 

What  kinds  of  module  expressions  are  pure?  All  module  values  are  clearly  pure,  including 
anonymous  structure  values  such  as 

struct  type  t  =  int;  val  x  =  3  end  (Mval) 

as  well  as  module  variables  like  LinkedList,  since  variables  are  values  in  a  call-by-value  language. 
Projections  from  pure  module  expressions  are  pure  as  well,  such  as  M. Substructure  where  M  is 
a  pure  expression. 

It  is  not  really  necessary,  though,  for  a  module  expression  to  be  completely  pure  in  order  for  it 
to  be  soundly  considered  projectible.  For  example,  the  structure  expression 

struct  type  t  =  int;  val  x  =  ref  3  end  (Mref) 

is  clearly  not  pure  in  the  usual  sense.  Specifically,  the  binding  for  the  x  component  has  the  effect  of 
allocating  a  new  memory  cell  and  returning  a  pointer  to  it,  and  every  time  ref  3  is  evaluated  it  will 
return  a  different  pointer.  Nonetheless,  it  is  fine  to  treat  Mref  as  projectible,  as  its  t  component 
will  always  be  defined  by  the  same  type  int. 

This  example  illustrates  that,  for  the  purpose  of  gauging  whether  it  is  sound  to  project  the 
type  components  from  a  module  expression,  all  that  really  matters  is  purity  with  respect  to  the  type 
components.  Let  us  thus  distinguish  two  notions  of  purity,  “dynamic  purity”  and  “static  purity.” 
A  dynamically  pure  module  is  completely  free  of  computational  effects.  A  statically  pure  module, 
on  the  other  hand,  may  have  computational  effects,  but  the  presence  of  effects  does  not  influence 
the  identities  of  the  module’s  type  components.  Dynamic  purity  clearly  entails  static  purity,  but 
static  purity  is  all  that  is  required  in  order  for  a  module  to  be  soundly  considered  projectible.^ 

2.1.2  Phase  Separation 

The  astute  reader  may  have  noticed  that  the  module  expression  Mgui  shown  above  is  subtly 
different  from  Lillibridge’s  example,  which  I  presented  in  Section  1.2.3.  The  original  version  is  as 
follows: 


if  n  <  20  then  LinkedList  else  HashTable  (Mdigt) 

The  difference  in  the  conditional  test  between  Mgui  ami  Mdict  is  a  significant  one.  Instead  of 
querying  the  state  of  the  GUI,  Mdigt  checks  whether  n  is  less  than  20,  which  is  a  pure  operation! 
Consider  plugging  Mdigt  in  for  M  in  the  scenario  of  Figure  2.1  (where  I  assume  static  scoping,  so 
that  both  copies  of  Mdigt  are  referring  to  the  same  variable  n.)  Variables  are  values,  so  although 
it  is  impossible  to  tell  statically  whether  X.t  and  Y.t  will  equal  LinkedList. t  or  Hash! able. t, 
it  is  clear  that  they  will  both  be  defined  by  the  same  one.  This  example  illustrates  that  the  static 
purity  of  an  expression  may  depend  on  the  dynamic  purity  of  its  free  variables;  the  static  purity  of 
Mdigt  depends  on  the  dynamic  purity  of  n,  i.e.,  that  n  is  instantiated  by  some  value. 


previous  version  of  this  work  (Dreyer  et  al.  [12])  used  the  terms  “statically  pure”  and  “dynamically  pure” 
to  mean  something  completely  different,  an  unfortunate  artifact  of  the  overloadability  of  the  terms  “static”  and 
“dynamic.”  For  those  familiar  with  the  terminology  of  our  previous  work,  see  Section  2.3  for  a  detailed  comparison. 


24 


CHAPTER  2.  A  UNIFYING  ACCOUNT  OF  ML  MODULES 


My  analysis  thus  far  implies  that  it  is  sound  to  treat  this  pure  version  of  the  dictionary  module 
expression  as  projectible.  However,  permitting  one  to  project  the  type  t  from  this  expression 
means  that  the  language  we  are  designing  must  support  a  form  of  dependent  type,  that  is,  a  type 
whose  identity  depends  on  run-time  information  {e.g.,  the  value  of  n)  and  cannot  be  determined 
statically.^  Dependent  types  severely  complicate  the  type  structure  of  a  language,  and  ML  does 
not  support  them.  To  introduce  them  vicariously  by  allowing  module  expressions  like  Mdict  to 
be  considered  projectible  would  constitute  a  major  extension  to  the  power  and  complexity  of  ML, 
which  is  not  the  purpose  of  the  module  system. 

To  avoid  the  need  for  true  dependent  types,  one  can  place  an  additional  requirement  on  pro¬ 
jectible  module  expressions,  which  I  call  “phase-separability”  (or  “separability,”  for  short).  A 
module  expression  is  phase-separable  if  the  identities  of  its  type  components  do  not  depend,  even 
in  a  pure  manner,  on  any  dynamic  values.^  Separability  ensures  not  only  that  a  module  expression 
is  soundly  projectible,  but  also  that  its  type  components  are  statically  well-determined  and  may 
thus  be  projected  out  without  fundamentally  expanding  the  type  structure  of  ML.  Of  the  module 
expression  examples  examined  above,  Mval  and  Mref  are  separable,  while  Mqui  and  Mdict  are 
not. 

To  summarize  the  discussion  so  far.  Figure  2.2  illustrates  the  relationships  between  the  classes 
of  statically  pure,  dynamically  pure,  and  separable  module  expressions,  as  well  as  how  the  modules 
Mgui  through  Mdict  ht  into  the  picture.  (It  is  probably  worth  the  reader’s  while  to  stop  and 
check  that  Figure  2.2  is  fully  understood  before  continuing.®) 

All  the  variants  of  the  ML  module  system  that  I  have  considered  in  Chapter  1  require  projectible 
modules  to  be  separable,  and  the  type  system  for  modules  that  I  will  describe  in  Chapters  3  and  4 
makes  this  requirement  as  well.  For  the  remainder  of  my  high-level  analysis,  however,  I  will  ignore 
the  practical  concern  that  motivates  this  requirement,  namely  the  desire  to  avoid  dependent  types. 
I  will  study  how  both  static  purity  and  separability  are  preserved  (or  not  preserved)  by  the  features 

®One  may  ask:  Aren’t  all  types  of  the  form  M.t  dependent  types,  since  M  may  contain  arbitrary  code?  The  answer 
is  no:  M.t  is  not  really  dependent  unless  the  identity  of  M’s  t  component  relies  on  the  evaluation  of  code  in  M,  as  is 
the  case  for  Mdict  .t. 

"^The  term  phase-separable  originates  from  Harper,  Mitchell  and  Moggi’s  view  of  modnles  as  having  a  compile-time 
phase  (or  static  part)  and  a  run-time  phase  (or  dynamic  part)  [30].  For  structures,  the  static  part  comprises  the  type 
components  and  the  dynamic  part  comprises  the  term  components.  For  fnnctors,  the  static  and  dynamic  parts  are  a 
bit  trickier  to  define,  but  I  will  do  so  precisely  in  Chapter  4. 

leave  it  as  an  (easy)  exercise  to  the  reader  to  concoct  an  example  of  a  modnle  expression  that  is  statically  pnre, 
but  neither  separable  nor  dynamically  pure.  The  picture  in  Figure  2.2  makes  room  for  this  class  of  modules,  but  they 
do  not  play  an  interesting  role  in  the  analysis. 
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of  the  ML  module  system,  but  I  will  only  require  projectible  modules  to  be  statically  pure,  not 
necessarily  separable.  Tracking  both  static  purity  and  separability  affords  us  a  richer  set  of  module 
classifications,  which  in  turn  allows  for  a  more  nuanced  account  of  data  abstraction.  Precisely  what 
I  mean  by  “more  nuanced”  will  be  made  clear  in  the  next  few  sections.  By  giving  ourselves  more 
freedom  within  this  theoretical  analysis,  we  will  be  able  to  see  more  clearly  (in  Section  2.2.1)  what 
is  lost  by  restricting  projectibility  in  practice  to  separable  modules. 

2.1.3  Module  Equivalence 

This  analysis  has  been  driven  by  the  question  of  how  to  define  projectibility,  but  an  important, 
closely  related  question  is  how  to  define  type  equivalence.  Suppose  we  are  given  two  projectible 
modules  M  and  N,  which  both  provide  a  type  component  t.  How  do  we  determine  if  M.t  =  N.t? 
If  the  signatures  of  M  and  N  specify  the  identity  of  t  to  be  transparently  equal  to  types  A  and  B, 
respectively,  then  the  problem  can  be  reduced  to  asking  whether  A  and  B  are  equivalent. 

Suppose,  though,  that  the  signatures  of  M  and  N  specify  t  opaquely.  In  that  case,  the  an¬ 
swer  is  that  M.t  =  N.t  so  long  as  M  and  N  are  “statically  equivalent,”  i.e.,  they  evaluate  to 
modules  with  equivalent  type  components.  In  fact,  the  notion  of  static  equivalence  has  already 
been  introduced  implicitly  in  the  definition  of  static  purity — statically  pure  modules  are  precisely 
those  modules  that  are  statically  equivalent  to  themselves.  An  alternative,  more  restrictive  notion 
of  module  equivalence  is  “dynamic  equivalence.”  Let  us  say  that  two  modules  are  “dynamically 
equivalent”  if  they  evaluate  to  module  values  that  are  equivalent  both  in  their  type  and  value  compo¬ 
nents.  Dynamic  equivalence  was  implicitly  introduced  above  when  I  defined  the  notion  of  dynamic 
purity — dynamically  pure  modules  are  precisely  those  modules  that  are  dynamically  equivalent  to 
themselves. 

Just  as  the  static  purity  of  an  expression  may  depend  in  general  on  the  dynamic  purity  of 
its  free  variables,  static  equivalence  depends  on  dynamic  equivalence.  For  example,  the  module 
expression  Mdict  defined  above  is  statically  (and  dynamically)  equivalent  to  itself,  but  only  under 
dynamically  equivalent  instantations  of  its  free  variable  n.®  The  type  components  of  separable 
module  expressions,  on  the  other  hand,  are  by  definition  indifferent  to  the  dynamic  components 
of  their  free  variables.  As  a  result,  a  separable  module  is  statically  equivalent  to  itself  under 
instantiations  of  its  free  variables  that  are  statically  equivalent,  regardless  of  whether  they  are 
dynamically  equivalent. 

In  order  to  keep  the  analysis  at  a  rather  informal,  intuitive  level,  I  have  been  deliberately 
vague  about  exactly  what  it  means  to  have  “equivalent  type  components”  or  “equivalent  value 
components,”  assuming  some  general  intuition  on  the  part  of  the  reader.  In  Chapter  4,  we  will  see 
a  concrete  module  calculus  in  which  these  notions  are  given  formal,  albeit  syntactic  and  necessarily 
conservative,  realizations.  In  the  meantime,  terms  like  “separable”  and  “statically  equivalent” 
should  be  taken  for  the  conceptual  picture  they  paint,  but  not  for  anything  more  formally  semantic. 

2.1.4  Total  vs.  Partial  Functors 

How  do  the  module  properties  of  purity  and  separability  interact  with  the  mechanisms  that  are 
shared  by  all  dialects  of  the  ML  module  system,  namely  sealing  and  functors!  Let  us  begin  with 
functors. 

®One  can  think  of  the  integer  n  here  as  a  module  that  just  contains  a  single  value  component  of  type  int. 
Correspondingly,  any  two  integers  are  trivially  statically  equivalent  because  they  have  no  type  components  at  all.  To 
be  dynamically  equivalent,  however,  they  must  be  equal  integers. 
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To  track  purity/separability  of  module  expressions  in  the  presence  of  functors,  the  chief  difhcnlty 
is  deciding  whether  a  functor  application  is  pure/separable  or  not,  given  jnst  the  signature  of  the 
functor  but  not  its  implementation.  A  common  method  for  tracking  purity  and  effects  in  the 
presence  of  ordinary  functions  is  to  distinguish  between  the  types  of  “total”  and  “partial”  functions, 
where  total  functions  are  those  whose  bodies  are  pure  and  partial  functions  are  those  whose  bodies 
are  (potentially)  impure. 

Lifting  this  idea  to  the  module  level,  let  us  distinguish  four  types  of  functors,  corresponding  to 
the  four  different  module  classifications  depicted  in  Figure  2.2; 

1.  “separably  total”  functors,  whose  bodies  are  separable  bnt  may  be  dynamically  impnre 

2.  “dynamically  total”  fnnctors,  whose  bodies  are  dynamically  pure  but  may  be  inseparable 

3.  “statically  total”  fnnctors,  whose  bodies  are  statically  pnre  but  may  be  inseparable  and/or 
dynamically  impure 

4.  “partial”  functors,  whose  bodies  may  be  statically  impnre 

It  should  be  clear  from  this  definition  that  these  functor  classifications  satisfy  the  same  subset 
relations  among  themselves  as  do  the  properties  of  separability,  dynamic  purity,  static  purity,  and 
static  imparity,  respectively. 

A  pleasing  property  of  the  total/partial  classification  is  that  it  corresponds  precisely  to  the 
distinction  between  applicative  and  generative  semantics  for  functors  described  in  Chapter  1.  To 
begin  with,  say  we  have  a  fnnctor  variable  F  whose  implementation  is  compiled  separately  bnt  whose 
result  signature  specifies  an  opaqne  type  component  t,  and  say  that  we  apply  F  to  a  separable 
module  expression  N.^  If  F’s  type  is  known  to  be  separably  total,  that  means  the  type  components 
of  F’s  body  are  statically  well-determined,  assuming  the  type  components  of  its  argument  are  as 
well.  Thus,  since  N  is  separable,  F(N)  is  separable,  too.  On  the  other  hand,  if  F’s  type  is  only 
known  to  be  partial,  then  F(N)  may  be  impure,  let  alone  inseparable. 

Plugging  F(N)  in  for  M  in  onr  scenario  from  Figure  2.1,  we  see  that  it  is  sound  to  consider  X.t 
equal  to  Y .  t  when  F  is  separably  total,  but  potentially  nnsonnd  to  do  so  when  F  is  partial.  In  other 
words,  separably  total  functors  behave  applicatively,  and  partial  functors  behave  generatively.  It 
is  reassuring  that  one  of  the  major  axes  in  the  design  space  of  modnles  can  be  nnderstood  simply 
in  terms  of  total  vs.  partial  functions. 

Now  what  about  functors  that  are  statically  total,  but  not  separably  total?  Interestingly, 
statically  total  functors  also  exhibit  applicative  semantics,  but  only  when  applied  to  dynamically 
pure  arguments!  To  see  this,  suppose  that  we  have  the  same  scenario  as  above  with  F  and  N,  except 
where  F  is  statically  total  and  N  is  statically  pure.  We  might  imagine  that,  just  as  separably  total 
functors  take  separable  arguments  to  separable  results,  statically  total  functors  take  statically  pure 
arguments  to  statically  pure  results.  But  this  is  not  the  case.  To  see  why,  let  N  be  the  expression 

if  buttonIsSelectedO 

then  struct  val  n  =  10  end 
else  struct  val  n  =  30  end 
and  let  F  be  defined  by  the  declaration 

functor  F(Arg  :  sig  val  n  :  int  end)  = 
let  val  n  =  Arg.n  in  Mdict  end 

general,  the  functor  being  applied  need  not  be  a  variable,  it  may  be  an  arbitrary  expression  F  of  functor  type. 
I  restrict  attention  here  to  the  case  when  F  is  a  variable,  mainly  for  the  sake  of  simplicity,  and  also  because  it  forces 
us  to  look  at  F’s  interface  and  not  at  its  implementation  to  determine  whether  its  application  is  pure. 
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If  F  is: 

separably  total 
separably  total 
dynamically  total 
statically  total 


And  N  is: 
separable 
statically  pure 
dynamically  pure 
dynamically  pure 


Then  F  (N)  is: 

separable 
statically  pure 
dynamically  pure 
statically  pure 


If  F  is: 

separably  total 
dynamically  total 
statically  total 


And  Ni  and  N2  are: 
statically  equivalent 
dynamically  equivalent 
dynamically  equivalent 


ThenF(Ni)  and  F(N2)  are: 
statically  equivalent 
dynamically  equivalent 
statically  equivalent 


Figure  2.3:  Semantic  Behavior  of  Different  Types  of  Functors 


Recall  that  Mdict  tests  whether  n  is  less  than  20  and,  depending  on  the  result,  returns  either 
LinkedList  or  HashTable.  This  functor  F  is  statically  total  because  its  body  is  statically  pure. 
Since  the  argument  N  does  not  have  any  type  components,  N  is  trivially  statically  pure  as  well. 
However,  the  application  F(N)  is  not  pure  in  any  sense;  depending  on  whether  the  GUI  button  is 
selected,  it  may  return  LinkedList  or  it  may  return  HashTable,  which  differ  in  both  their  static 
and  dynamic  components. 

The  intuitive  reason  that  statically  total  functors  do  not  preserve  the  static  purity  of  their 
arguments  is  simple.  As  pointed  out  in  Section  2.1.2,  the  static  purity  of  an  expression  may 
depend  on  the  dynamic  purity  of  its  free  variables;  in  particular,  the  static  purity  of  Mdict  rests 
on  the  dynamic  purity  of  Arg.n.  Thus,  so  long  as  a  statically  total  functor  like  F  is  applied  to  a 
dynamically  pure  argument  (which  N  in  this  example  was  not),  the  result  will  be  statically  pure 
and  the  functor  will  behave  applicatively.  Similarly,  it  is  easy  to  see  that  the  application  of  a 
dynamically  total  functor  to  a  dynamically  pure  argument  yields  a  dynamically  pure  result;  but 
nothing,  for  instance,  can  be  said  about  the  application  of  a  statically  or  dynamically  total  functor 
to  a  separable  argument. 

Figure  2.3  summarizes  the  behavior  of  different  types  of  functors  on  different  types  of  arguments. 
The  table  only  lists  functor-argument  pairs  for  which  something  positive  can  be  stated  about  the 
result.  In  addition  to  the  cases  mentioned  so  far,  the  table  includes  the  application  of  a  separably 
total  functor  to  a  statically  pure  argument.  Such  an  application  must  produce  a  statically  pure 
result,  because  the  separability  of  the  functor  body  ensures  that  the  type  components  of  the  result 
can  only  depend  on  the  type  components  of  the  argument,  which  by  assumption  are  pure. 

Figure  2.3  also  describes  how  total  functors  preserve  equivalence  of  their  arguments,  which  is 
unsurprisingly  in  a  direct  correspondence  with  how  they  preserve  purity  of  their  arguments.  For 
example,  just  as  statically  total  functors  take  dynamically  pure  arguments  to  statically  pure  results, 
they  also  take  dynamically  equivalent  arguments  to  statically  equivalent  results.  Clearly,  though,  a 
statically  total  functor  like  the  one  defining  F  above  will  not  necessarily  produce  statically  equivalent 
results  given  arguments  that  are  merely  statically  equivalent. 


2.1.5  Sealing  as  a  Form  of  Information  Hiding 

Now  let  us  turn  to  the  sealing  mechanism.  Returning  to  the  scenario  from  Figure  2.1,  suppose  we 
plug  in  for  M  the  sealed  module  expression 
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struct  type  set  =  int  list  ...  end  :>  INT_SET  (Mseal) 

where  the  signature  INT_SET  holds  the  definition  of  the  set  type  abstract.  This  expression  was 
used  to  define  the  IntSet  module  in  Chapter  1.  As  the  sealing  in  Mseal  does  not  have  any  actual 
run-time  effect,  the  evaluation  of  Mseal  will  always  result  in  a  module  value  that  defines  set  to 
be  the  same  type,  int  list.  Thus,  Mseal  is  an  example  of  a  separable  module  expression,  and  it 
is  perfectly  sound  to  treat  it  as  projectible. 

Unfortunately,  as  the  scenario  also  illustrates,  treating  Mseal  as  projectible  has  the  effect  of 
violating  data  abstraction!  Specifically,  X.set  and  Y.set  will  be  deemed  equivalent,  even  though 
nothing  about  the  interface  INT_SET  with  which  X’s  and  Y’s  implementations  were  independently 
sealed  indicates  anything  that  would  connect  their  respective  set  types.  In  order  to  make  any 
claim  that  our  type  system  provides  support  for  data  abstraction,  we  must  therefore  ensure  that 
sealed  module  expressions  like  Mseal,  regardless  of  whether  they  are  separable,  are  not  considered 
projectible.  Indeed,  as  one  would  expect,  no  actual  variants  of  the  ML  module  system  permit  such 
sealed  module  expressions  to  appear  inside  types. 

How  can  we  account  for  this  dissonance  between  separability  and  projectibility  with  respect  to 
sealed  module  expressions?  One  view  is  to  say  that  the  whole  point  of  sealing  is  to  prevent  one  from 
using  a  module  in  ways  that  are  perfectly  sound,  but  that  violate  abstraction.  It  should  therefore 
not  come  as  a  surprise  that  sealing  forces  a  distinction  to  be  made  between  the  class  of  projectible 
modules,  from  which  one  is  allowed  to  project  types,  and  the  class  of  pure/separable  modules,  from 
which  it  would  be  sound  to  be  able  to  project  types. 

Another  way  to  account  for  the  dissonance  is  to  assert  that  in  fact  we  have  made  a  mistake: 
sealed  module  expressions  like  Mseal  should  not  even  be  considered  pure,  let  alone  projectible. 
Sealing  should  render  a  module  expression  statically  impure,  because  every  time  one  evaluates  a 
sealed  module  expression  at  run  time,  one  generates  new  and  different  abstract  types.  That  sealed 
module  expressions  must  be  considered  non-projectible  then  follows  as  a  matter  of  soundness. 

The  point  of  dispute  between  these  views,  i.e.,  the  question  of  whether  or  not  sealing  should  be 
treated  as  an  effectful  operation,  is  not  merely  a  pedantic  one.  It  makes  a  real  difference  because  it 
affects  whether  functors  that  contain  sealing  in  their  bodies  are  deemed  total  or  partial.  Under  the 
first  interpretation  of  sealing  as  a  no-op  that  has  no  effect  on  the  purity  of  a  module  expression, 
one  can  employ  arbitrary  sealing  in  the  body  of  a  functor,  and  the  functor  may  still  be  considered 
total/applicative,  so  long  as  its  body  is  otherwise  pure.  Under  an  effectful  interpretation  of  sealing, 
however,  any  sealing  in  the  body  of  a  functor  renders  the  functor  partial/generative  because  its 
body  is  considered  impure. 

The  dispute  could  be  settled  quite  easily  if  one  of  the  interpretations  led  to  a  semantics  for 
functor-sealing  interaction  that  was  clearly  preferable,  but  neither  one  does.  We  have  already  seen 
examples  in  Chapter  1  to  support  this  observation.  Take  the  Set  functor,  for  example.  Its  body  is 
sealed,  and  yet,  as  I  argued  in  Section  1.2.7,  it  is  appropriate  to  consider  the  functor  applicative. 
On  the  other  hand,  recall  the  SymbolTable  functor  from  Section  1.2.6.  Its  body  is  sealed  as  well, 
but  it  is  necessary  for  the  functor  to  be  considered  generative  in  order  to  guarantee  the  program 
invariant  that  the  Fail  exception  will  never  be  raised. 

The  solution  that  I  propose,  then,  is  to  accept  that  there  are  multiple  varieties  of  sealing,  which 
are  distinguished  from  one  another  by  how  much  information  they  hide  about  the  module  being 
sealed.  Figure  2.4  illustrates  the  semantic  effects  of  several  varieties  of  sealing  when  applied  to  a 
separable  module  M. 

The  weakest  form  of  sealing,  which  I  call  “basic  sealing”  and  denote  by  M  :>SIG,  seals  M  with 
the  signature  SIG  but  does  not  hide  any  information  about  M’s  separability.  The  only  effect  of 
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Statically  Pure 


Separable 


Projectible 

M 


M  :>  SIG 


insep(M  :>  SIG) 


impure(M  :>  SIG) 


Figure  2.4;  Semantic  Effects  of  Sealing 


basic  sealing  is  to  render  the  module  non-projectible,  thus  ensuring  that  the  identities  of  any  type 
components  specified  opaquely  in  the  signature  SIG  are  held  abstract.  In  contrast,  the  strongest 
form  of  sealing,  which  I  call  “impure  sealing”  and  denote  by  impure (M  :>SIG),  not  only  renders 
the  module  non-projectible,  but  also  hides  the  fact  that  it  is  statically  pure.  Consequently,  while 
basic  sealing  may  be  used  in  the  body  of  a  separably  total  functor,  impure  sealing  may  only  be 
used  in  the  body  of  a  partial  functor. 

While  the  semantics  of  the  basic  and  impure  forms  of  sealing  correspond  precisely  to  the  two 
interpretations  of  sealing  discussed  above,  thinking  about  sealing  as  a  form  of  information  hiding 
suggests  yet  another  form  of  sealing  in  between  them,  which  I  call  “inseparable  sealing”  and  denote 
by  insepCM  :>SIG).  As  one  might  surmise  from  the  name,  inseparable  sealing  hides  the  fact  that 
M  is  separable,  but  does  not  obscure  the  knowledge  that  M  is  statically  or  dynamically  pure.®  As 
a  result,  employing  inseparable  sealing  in  the  body  of  a  functor  forces  the  functor  to  be  considered 
at  best  statically  or  dynamically  total,  but  not  separably  total. 

Each  of  these  three  different  forms  of  sealing  can  be  semantically  desirable  in  different  circum¬ 
stances.  Consider,  for  instance,  the  SymbolTable  functor.  Every  time  the  body  of  that  functor 
is  evaluated,  it  generates  a  new  hash  table  in  memory  and,  along  with  it,  a  new  type  of  integer 
symbols  that  work  as  valid  indices  into  that  particular  hash  table.  Of  course,  there  is  no  way 
in  ML  to  define  a  subtype  of  integers  that  only  contains  valid  indices  into  a  hash  table.  Impure 
sealing,  however,  allows  us  to  mimic  such  a  definition.  By  using  impure  sealing  in  the  body  of  the 
SymbolTable  functor,  we  will  not  only  hide  the  definition  of  the  symbol  type,  but  also  indicate 
that  the  symbol  type  is  dependent,  at  least  notionally,  on  a  data  structure  created  at  run  time  by 
an  effectful  operation. 

What  about  the  Set  functor?  The  purpose  of  sealing  its  body  is  not  to  tie  the  set  type  to  any 
run-time  state,  for  the  Set  functor  is  purely  functional  and  has  no  run-time  state.  Thus,  impure 
sealing  is  inappropriate.  In  writing  the  Set  functor,  we  would  really  like  to  define  set  as  the  type 
of  Item,  item  list’s  that  are  ordered  according  to  the  Item,  compare  function.  We  cannot  write 
such  a  type  definition,  of  course,  because  ML  lacks  dependent  types.  Inseparable  sealing,  however, 
allows  us  to  mimic  it.  By  using  inseparable  sealing  in  the  body  of  the  Set  functor,  we  not  only 
hide  the  definition  of  the  set  type,  but  also  “give  the  impression”  that  the  set  type  depends  on 

®One  can  imagine  another  intermediate  form  of  sealing,  “dynamically  impnre  sealing,”  which  hides  the  fact  that 
the  underlying  module  is  dynamically  pure — if  that  is  even  true  in  the  first  place — but  does  not  obscure  whether  the 
module  is  separable  or  statically  pure.  I  have  not  included  this  variety  of  sealing  in  the  analysis  only  because  I  have 
not  yet  seen  any  practical  use  for  it. 
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the  entire  functor  argument,  not  only  on  the  item  type  but  also  on  the  compare  function,  i.e., 
that  set  is  a  dependent  type.  As  a  consequence,  the  Set  functor  will  be  considered  statically  (but 
not  separably)  total,  and  thus  it  will  only  return  equivalent  set  types  when  given  dynamically 
equivalent  arguments,  i.e.,  when  given  equivalent  item  types  and  equivalent  compare  functions. 

If  we  were  to  use  basic  sealing  instead  of  inseparable  sealing  in  the  body  of  the  Set  functor,  then 
the  functor  would  be  considered  separably  total  and  would  return  statically  equivalent  results  when 
given  merely  statically  equivalent  arguments.  As  pointed  out  in  Section  1.2.6,  this  can  lead  to  what 
amounts  to  a  violation  of  data  abstraction.  In  particular,  if  we  were  to  apply  the  functor  to  two  item 
modules,  IntLt  and  IntGt,  which  both  define  the  item  type  to  be  int,  but  which  provide  different 
comparison  functions  on  integers  (one  <  and  one  >),  then  Set  (IntLt)  .set  and  Set  (IntGt)  .set 
would  be  deemed  equivalent  types.  They  are  not,  however,  semantically  compatible  types;  values 
of  the  first  type  are  integer  lists  ordered  by  <  and  values  of  the  second  type  are  integer  lists  ordered 
by  >.  Although  passing  values  of  type  Set  (IntLt)  .set  to  the  insert  function  from  Set  (IntGt) 
does  not  constitute  a  violation  of  soundness,  it  does  constitute  a  violation  of  abstraction. 

In  short,  the  inseparable  and  impure  forms  of  sealing  are  useful  for  pretending  that  a  type  is 
dependent  on  a  dynamic  value  or  on  the  result  of  a  dynamic  effectful  computation,  respectively. 
Conversely,  basic  sealing  is  useful  when  no  pretensions  of  dependent  types  are  required  and  the  sole 
purpose  of  the  sealing  is  to  hide  the  identity  of  a  type.  One  such  situation  arises  when  sealing  a 
module  that  is  completely  self-contained  and  does  not  depend  at  all  on  the  context  in  which  it  is 
defined.  Another  example  is  the  type-theoretic  interpretation  of  ML  datatype  declarations  given 
by  Harper  and  Stone  [32].  To  encode  the  semantics  that  each  datatype  declaration  in  ML  generates 
a  distinct  abstract  type.  Harper  and  Stone  translate  datatype  declarations  into  bindings  of  sealed 
modules.  These  modules  have  a  highly  restricted  form:  they  provide  a  single  recursive  type,  along 
with  two  coercion  functions,  one  a  “fold”  into  the  recursive  type  and  the  other  an  “unfold”  out  of 
the  recursive  type.  While  a  datatype  module  may  depend  on  other  types,  it  cannot  depend  on  any 
dynamic  values.  The  purpose  of  sealing  it  is  solely  to  hide  the  implementation  of  the  underlying 
data  type  as  a  recursive  type,  so  the  best  choice  for  interpreting  datatype  declarations  would  be 
to  use  basic  sealing. 

To  conclude  this  discussion,  it  is  worth  noting  a  complaint  that  is  sometimes  leveled  against  both 
the  basic  and  inseparable  forms  of  sealing,  namely  that  they  interact  strangely  with  beta-reduction. 
For  example,  if  we  plug  Set  (IntLt)  in  for  M  in  our  scenario  from  Figure  2.1,  then  X.  set  will  equal 
Y .  set.  If  on  the  other  hand  we  substitute  for  M  the  result  of  beta-reducing  Set  (IntLt) ,  then  X .  set 
will  not  equal  Y.set,  because  each  set  type  will  result  from  a  separately  sealed  implementation  of 
sets.  As  a  consequence,  in  the  presence  of  basic  and/or  inseparable  sealing,  beta-reduction  of  total 
functor  applications  is  not  guaranteed  to  be  type-preserving. 

From  a  methodological  standpoint,  the  interaction  of  basic  and  inseparable  sealing  with  beta- 
reduction  is  admittedly  somewhat  unpleasant.  I  would  argue,  however,  that  this  deficiency  is 
mitigated  by  the  more  accurate  propagation  of  type  information  that  these  sealing  constructs 
afford  (when  the  full  power  of  impure  sealing  is  not  required).  Moreover,  as  far  as  type  safety 
of  the  module  language  is  concerned,  the  lack  of  type  preservation  in  the  presence  of  basic  and 
inseparable  sealing  is  not  a  serious  issue — sealing  has  no  actual  run-time  effect,  so  we  can  simply 
erase  all  uses  of  it  before  executing  the  program. 

2.1.6  Squeezing  the  Balloon 

I  have  argued  that  several  different  levels  of  information  hiding,  expressed  by  different  varieties 
of  sealing,  are  useful  and  appropriate  in  different  circumstances.  In  the  interest  of  minimality. 
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though,  it  is  reasonable  to  ask  whether  such  an  explosion  of  sealing  constructs  is  truly  necessary. 
In  particular,  I  have  motivated  the  different  kinds  of  sealing  in  terms  of  how  they  force  different 
classifications  for  the  functors  in  whose  bodies  they  appear — using  inseparable  sealing  in  the  body 
of  the  Set  functor  forces  it  to  be  classified  as  statically  total,  using  impure  sealing  in  the  body  of 
the  SymbolTable  functor  forces  it  to  be  classified  as  partial,  etc.  Instead,  why  not  dispense  with 
the  multiple  forms  of  sealing,  and  instead  allow  the  Set  (resp.  SymbolTable)  functor  to  be  declared 
as  statically  total  (resp.  partial)  directly? 

The  answer  is  that  this  is  a  perfectly  valid,  and  essentially  equivalent,  alternative.  If  we  assume 
inseparable  and  impure  sealing  mechanisms  as  primitive  (as  we  have),  then  we  can  encode  a  stati¬ 
cally  total  or  partial  functor  declaration  as  one  that  implicitly  seals  its  body  with  the  appropriate 
level  of  sealing.  Conversely,  if  we  assume  basic  sealing  as  the  only  primitive  form  of  sealing,  but 
allow  different  primitive  forms  of  functor  declaration,  then  we  can  encode  impure(M  :>SIG)  as 

let  partialfunctor  F()  =  M:>SIG  in  F()  end 

and  we  can  encode  insepCM  :>SIG)  analogously  using  a  statically  total  functor  declaration.  In 
short,  there  is  more  than  one  way  to  squeeze  the  balloon  when  it  comes  to  supporting  different 
levels  of  information  hiding.  Under  the  latter  approach,  however,  it  is  important  that  basic  sealing 
is  the  one  we  take  as  primitive,  for  that  is  the  weakest  form  of  sealing  and  it  cannot  be  encoded 
directly  in  terms  of  the  other  forms  of  sealing. 

The  main  reason  I  have  chosen  to  distinguish  different  forms  of  sealing  is  to  emphasize  the  fact 
that,  while  each  modern  variant  of  the  ML  module  system  supports  exactly  one  form  of  sealing,  there 
is  no  universally  accepted  semantics  of  sealing.  In  some  dialects  “sealing”  means  basic  sealing,  and 
in  other  dialects  it  means  impure  sealing.  (See  Section  2.2.1  for  examples.)  The  semantic  framework 
I  have  developed  here  clarifies  how  the  different  interpretations  of  the  “sealing”  construct  relate  to 
one  another. 

2.1.7  Projectibility  and  Transparency 

Based  on  the  analysis  thus  far,  we  can  say  that  a  module  expression  is  projectible  whenever  it 
is  statically  pure  and  free  of  sealing.  This  final  section  of  my  analysis  of  ML  modularity  shows 
how  we  may  also  characterize  projectibility  in  terms  of  transparency.  It  is  based  on  the  following 
observation:  it  is  fine  to  treat  any  module  expression  as  projectible  if  it  has  a  transparent  signature. 

The  basis  for  this  observation  is  simple:  if  a  module  expression  M  has  a  transparent  signature, 
then  that  signature  uniquely  specifies  the  identities  of  M’s  type  components.  As  the  type  compo¬ 
nents  of  M  must  therefore  be  the  same  every  time  it  is  evaluated,  M  may  at  least  be  considered 
statically  pure.  Furthermore,  if  we  plug  M  into  the  scenario  from  Figure  2.1,  then  we  see  that  it 
doesn’t  really  matter  whether  M  is  considered  projectible  or  not  because,  either  way,  the  trans¬ 
parent  definition  of  t  in  M’s  signature  ensures  that  X.t  will  equal  Y.t.  Certainly,  treating  M  as 
projectible  does  not  break  any  abstraction  guarantees. 

Although  it  is  unclear  whether  treating  transparent  modules  as  projectible  serves  any  practical 
purpose,  the  observation  that  such  modules  are  statically  pure  is  definitely  important.  For  example, 
suppose  there  is  some  functor  of  partial  signature  called  F,  and  say  that  we  define  the  following 
functors  that  make  use  of  it: 

functor  G  (X  :  SIG)  =  (struct  ...  F(X)  ...  end  :>  TSIG) 
functor  OpaqueG  (X  :  SIG)  =  G(X)  :>  OSIG 

Here,  TSIG  is  a  transparent  signature  and  OSIG  is  a  signature  with  some  opaque  type  specifications. 
The  idea  here  is  that  G’s  body  may  be  impure  in  the  sense  that  its  calls  to  F  may  have  computational 
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effects  and  result  in  the  creation  of  abstract  types,  but  none  of  these  impurities  or  abstract  types 
are  visible  to  the  outside  of  G  because  its  body  is  sealed  with  the  transparent  signature  TSIG.  It  is 
therefore  safe  to  treat  G  as  total,  and  consequently  it  is  safe  to  treat  OpaqueG  as  total,  too. 

The  reader  may  wonder;  what  is  the  point  of  OpaqueG  in  this  example?  Well,  in  some  sense, 
whether  G  is  treated  as  total  or  partial  does  not  matter  very  much  for  G  itself — regardless,  appli¬ 
cations  of  G  will  result  in  modules  with  equivalent  type  components  because  its  result  signature  is 
transparent.  Not  so,  however,  for  OpaqueG.  If  G  is  considered  partial,  i.e.,  if  we  do  not  observe  that 
transparent  modules  are  pure,  then  the  body  of  OpaqueG  will  be  considered  impure  as  well,  and 
OpaqueG  will  be  treated  as  partial.  In  that  case,  repeated  applications  of  OpaqueG  will  not  result  in 
modules  with  equivalent  type  components  because  OpaqueG’s  result  signature  is  not  transparent. 
This  example  illustrates  that  treating  transparent  modules  as  pure  is  not  merely  a  pedantic  issue, 
it  can  have  an  actual  effect  on  the  semantics  of  data  abstraction. 

We  have  seen  that  transparent  modules  may  be  considered  projectible.  What  about  the  con¬ 
verse:  can  projectible  modules  always  be  given  transparent  signatures?  Indeed.  To  take  a  simple 
example,  if  M  is  a  projectible  module  with  signature  sig  type  t  end,  then  clearly  M  can  also 
be  given  the  transparent  signature  sig  type  t  =  M.t  end,  since  M’s  t  component  is  certainly 
equal  to  M.t.  In  type-theoretic  accounts  of  ML  modules,  the  act  of  giving  a  projectible  module  a 
transparent  signature  is  often  referred  to  as  “signature  strengthening”  [69]  or  “selfification”  [28] .  It 
is  primarily  useful  in  computing  a  most-precise  (or  “principal” )  signature  for  M  when  the  identities 
of  M’s  type  components  cannot  otherwise  be  discerned  by  examining  it,  e.y.,  when  M  is  a  variable. 

In  conclusion,  I  have  shown  that  projectibility  and  transparency  are  ultimately  equivalent  prop¬ 
erties.  This  gives  us  an  alternative  perspective  on  projectibility,  but  it  does  not  mean  that  we  should 
abandon  our  previous  characterization  of  it  and  use  transparency  instead  as  the  sole  criterion.  For 
certain  modules,  notably  variables,  their  transparency  is  predicated  on  the  existing  knowledge  that 
they  are  projectible,  not  the  other  way  around.  Nevertheless,  if  a  module  does  have  a  transparent 
signature,  treating  it  as  statically  pure  is  semantically  valid  and  in  some  cases  desirable. 


2.2  Fruits  of  the  Analysis 

The  hrst  section  of  this  chapter  has  developed  informally  what  one  might  call  an  “ML  module  super¬ 
system”  in  which  distinctions  are  made  between  several  interesting  types  of  module  expressions, 
functors,  and  sealing  mechanisms.  This  super-system  is  not  itself  a  language  design,  but  it  is 
useful  because  it  provides  a  unifying  conceptual  framework — different  dialects  of  the  ML  module 
system  may  be  understood  as  conservative  approximations  of  the  super-system  that  only  recognize 
certain  distinctions  and  only  support  certain  subsets  of  features.  The  conservativity  of  the  existing 
dialects  is  due  partly  to  practical  concerns  such  as  decidability  of  typechecking,  and  partly  to 
actual  weaknesses  in  these  dialects  that  the  super-system  enables  us  to  articulate  more  clearly.  In 
Section  2.2.1,  I  will  show  how  the  design  points  discussed  in  Chapter  1  may  be  situated  in  this 
chapter’s  conceptual  framework.  In  Sections  2.2.2  and  2.2.3,  I  will  describe  a  new  module  system 
design  that  is  less  conservative  and  supports  more  features  of  the  super-system  than  any  of  the 
existing  designs  while  still  admitting  effective  typechecking. 

2.2.1  Understanding  the  Existing  ML  Module  System  Designs 

Before  re-examining  the  existing  ML  dialects  individually,  it  is  important  to  note  that  there  is  one 
sense  in  which  they  are  all  conservative — namely,  they  all  require  projectible  modules  to  be  not  just 
statically  pure  but  also  phase-separable.  As  discussed  in  Section  2.1.2,  this  requirement  ensures  that 
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types  projected  from  module  expressions  are  normal,  non-dependent  types.  As  a  result,  however, 
modules  like  Mdict  that  are  statically  pure  but  inseparable  are  treated  the  same  as  modules 
like  Mgui  that  are  impure.  In  other  words,  the  distinction  between  “inseparable”  and  “impure” 
becomes  moot.  Inseparable  sealing  has  the  same  effect  as  impure  sealing,  and  the  only  functor 
classifications  worth  tracking  are  “separably  total”  and  “partial.”  (Hence,  for  the  remainder  of 
this  section,  I  will  use  “total”  as  shorthand  for  “separably  total.”)  Furthermore,  static  equivalence 
of  separable  modules  only  depends  on  the  static  equivalence  of  their  free  variables,  so  dynamic 
equivalence  does  not  play  a  part  in  the  static  semantics  of  the  existing  dialects.  This  makes  sense; 
module  equivalence  is  only  relevant  to  deciding  type  equivalence;  since  types  are  non-dependent  in 
the  existing  dialects,  whether  two  types  are  equivalent  cannot  depend  on  the  equivalence  of  any 
dynamic  values. 

While  restricting  projectibility  to  separable  modules  clearly  simplifies  the  static  semantics  of 
the  language,  it  also  induces  a  loss  of  expressiveness.  Specifically,  it  restricts  the  sealing  mechanism 
to  two  variants:  basic  and  inseparable/impure.  (The  latter  variant  I  will  refer  to  hereafter  simply 
as  “impure.”)  This  is  problematic  in  cases  like  the  Set  functor,  for  which,  in  the  full  super-system, 
inseparable  sealing  provided  a  superior  intermediate  choice  to  the  two  extremes  of  basic  and  impure 
sealing.  In  the  absence  of  dependent  types,  the  programmer  must  choose  between  one  of  the  less 
appealing  extremes,  and  neither  one  is  clearly  preferable  to  the  other. 

First-Class  vs.  Second-Class  Modules  Harper  and  Lillibridge’s  hrst-class  module  calculus  [28] 
(hereafter,  HL)  employs  a  very  conservative  judgment  of  separability.  Specihcally,  it  considers  a 
module  to  be  separable  if  and  only  if  it  is  a  value.®  The  reason  for  this  conservativity  is  that  in  HL 
module  expressions  are  freely  intermingled  with  “core”  ML  expressions,  and  it  is  difficult  to  track 
the  purity  of  core  ML  expressions  effectively.  Since  neither  functor  applications  nor  sealed  module 
expressions  are  values,  both  kinds  of  expressions  are  considered  inseparable.  In  other  words,  HL 
treats  all  functors  as  partial/generative  and  only  supports  the  impure  form  of  sealing. 

In  the  remaining  variants  of  the  ML  module  system,  the  module  language  is  “second-class”  in 
the  sense  that  it  exists  on  a  separate  layer  from  the  core  language  and  provides  a  restricted  set  of 
constructs.  In  particular,  aside  from  impure  sealing,  these  second-class  languages  are  so  restricted 
that  they  do  not  even  provide  a  way  to  write  an  inseparable  module.  (For  example,  the  inseparable 
module  expressions  Mqui  and  Mdict  dehned  earlier  in  this  chapter  are  not  expressible  in  any  of  the 
existing  dialects  except  HL.)  It  is  much  easier  to  accurately  decide  whether  modules  are  separable 
in  a  second-class  module  system  than  in  a  hrst-class  one,  because  the  only  source  of  inseparability 
is  the  impure  sealing  mechanism. 

Standard  ML  Nevertheless,  Leroy’s  “manifest  types”  calculus  [42],  which  among  the  type- 
theoretic  accounts  of  ML  modules  is  the  one  that  most  closely  approximates  the  Standard  ML 
’97  module  system,  axiomatizes  separability  in  essentially  the  same  manner  as  the  HL  calculus. 
The  only  difference  is  that  Leroy,  as  well  as  SML,  only  allows  projections  of  types  from  modules 
that  are  in  named  form,  i.e.,  variables  and  projections  from  variables,  also  known  as  “paths.”  In 
terms  of  actual  programming,  this  does  not  result  in  any  fundamental  loss  of  expressiveness  be¬ 
cause  types  projected  from  arbitrary  module  values  may  always  be  beta-reduced  either  to  core  ML 
types  or  to  paths.  However,  given  that  the  SML  module  language  is  second-class,  its  judgment  of 
separability  and  its  assumption  that  all  functors  are  partial  are  both  unnecessarily  conservative. 

®The  notion  of  value  that  Harper  and  Lillibridge  use  extends  the  traditional  call-by-value  notion  of  value  to  include 
projections  from  values. 
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Objective  Caml  Leroy’s  “applicative  functor”  calculus  [43]  (along  with  Objective  Caml,  which 
is  based  on  it  [41])  exhibits  one  way  of  addressing  this  deficiency.  It  is  identical  to  the  manifest 
types  calculus  except  that,  instead  of  treating  all  functors  as  partial/generative,  it  assumes  that 
all  functors  are  total/applicative.  This  assumption  is  only  justifiable  so  long  as  all  modules  are 
separable,  which  in  turn  is  only  true  in  the  absence  of  impure  sealing.  Thus,  O’Caml’s  treatment 
of  all  functors  as  total  implies  that  it  only  supports  the  basic  form  of  sealing. 

While  all  modules  are  separable  in  O’Caml,  not  all  modules  are  projectible.  O’Caml  imposes  a 
named  form  restriction  on  projectible  modules,  which  extends  SML’s  notion  of  “path”  to  include 
functor  applications  where  the  functor  and  argument  are  both  paths.  For  instance,  while  both 
Set(IntLt)  and  Set  (struct  .  .  .  end)  are  considered  separable  in  O’Caml,  only  the  former  is 
considered  projectible.  One  way  to  account  for  the  named  form  restriction  in  the  terms  of  this 
chapter  is  to  imagine  that  every  structure  expression  struct  .  .  .  end  in  O’Caml  implicitly  contains 
a  sealed  submodule  defining  an  abstract  type.  Hence,  the  only  projectible  module  expressions  are 
those  that  do  not  contain  struct  expressions,  i.e.,  those  in  named  form. 

Another  notable  facet  of  the  O’Caml  module  system  is  its  notion  of  syntactic  module  equiv¬ 
alence.  The  super-system  dictates  that  static  equivalence  is  to  be  used  when  comparing  the  ar¬ 
guments  of  separably  total  functors  (see  Figure  2.3).  While  syntactic  equivalence  is  indeed  a 
conservative  approximation  of  static  equivalence,  it  is  also  in  many  cases  a  conservative  approx¬ 
imation  of  dynamic  equivalence.  In  particular,  if  we  restrict  attention  to  module  paths  in  the 
SML  sense  (i.e.,  not  including  functor  applications),  then  syntactic  equivalence  implies  dynamic 
equivalence  because  SML  paths  are  always  values.  On  the  other  hand,  the  O’Caml  path  F(X)  is 
syntactically  and  statically  equivalent  to  itself,  but  there  is  nothing  to  imply  that  it  is  dynami¬ 
cally  equivalent  to  itself  because  its  evaluation  may  have  computational  effects.  The  implication 
of  the  sometimes-static/sometimes-dynamic  nature  of  syntactic  equivalence  is  that,  when  applied 
to  certain  arguments,  functors  in  O’Caml  behave  as  if  they  were  separably  total,  while  on  other 
arguments  they  behave  as  if  they  were  statically  total. 

Russo  In  his  thesis,  Russo  dehnes  two  module  languages  [65].  The  first  language  closely  follows 
SML,  supporting  only  partial/generative  functors  and  impure  sealing.  The  second  language,  which 
Russo  describes  in  a  chapter  on  “higher-order  modules,”  is  much  like  O’Caml,  supporting  only 
total/applicative  functors  and  basic  sealing.  Unlike  O’Caml,  though,  it  uses  full  static  equivalence 
to  compare  functor  arguments.  For  example,  IntLt  and  IntGt  are  considered  equivalent  in  Moscow 
ML  despite  having  inequivalent  value  components. 

The  module  system  in  Moscow  ML  is  a  problematic  merging  of  the  two  module  languages  from 
Russo’s  thesis — problematic  in  the  sense  that  it  does  not  correctly  track  separability.  Specifically, 
as  mentioned  in  Section  1.2.7,  the  generativity  of  a  partial  functor  may  be  defeated  in  Moscow 
ML  by  eta-expanding  it  into  a  total/applicative  functor.  This  is  clearly  a  mistaken  design,  since  in 
general  a  partial  functor  cannot  soundly  be  coerced  into  a  total  signature.  It  has  also  been  shown 
to  lead  to  an  unsoundness  in  the  language  [9]. 

Shao  Shao’s  type  system  for  modules  [69]  is  the  only  existing  design  to  correctly  support  both 
total  and  partial  functors  in  one  language.  It  only  provides  one  sealing  mechanism,  however,  and  it 
is  the  impure  form  of  sealing.  As  a  result,  when  sealing  is  used  in  the  body  of  a  functor,  it  forces  the 
functor  to  be  treated  as  partial/generative.  This  severely  limits  the  kind  of  total  functors  one  can 
write  in  practice  because  the  presence  of  any  sealed  submodule — even  a  datatype  declaration — in 
the  body  of  a  functor  will  be  considered  an  instance  of  impure  sealing  and  thus  render  the  functor 
partial.  The  one  exception  to  this  rule  is  that,  when  the  body  of  a  functor  can  be  given  a  transparent 
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signature,  Shao’s  calculus  will  allow  the  functor  to  be  considered  total/applicative.  As  explained  in 
Section  2.1.7,  this  exception  is  semantically  justified  because  transparency  implies  purity.  Finally, 
like  Moscow  ML,  Shao  employs  full  static  equivalence  when  comparing  functor  arguments. 


Summary  and  Discussion  All  of  the  existing  dialects  of  ML  described  in  Chapter  1  take  sepa¬ 
rability  as  a  precondition  for  projectibility.  By  doing  this,  they  avoid  the  need  for  dependent  types, 
but  they  conflate  the  notions  of  inseparability  and  impurity  as  far  as  typechecking  is  concerned. 
Consequently,  there  are  only  two  kinds  of  functors  recognized  by  these  dialects — separably  total 
and  partial — and  only  two  kinds  of  sealing — basic  and  impure.  The  inability  to  support  statically 
total  functors  and  inseparable  sealing  is  a  fundamental  limitation  of  the  ML  module  system  which 
I  will  not  attempt  to  address  in  this  thesis.  Whether  these  features  can  be  supported  without  the 
need  for  true  dependent  types  remains  an  open  question,  one  for  which  I  suggest  some  potential 
solutions  in  Chapter  10  on  future  work. 

With  the  exception  of  Harper  and  Lillibridge’s  calculus,  all  the  existing  dialects  treat  the  module 
language  as  second-class,  meaning  that  there  is  no  way  to  write  a  module  expression  that  is  truly 
impure  or  inseparable.  There  is  a  basic  tradeoff  here:  a  first-class  module  language  like  the  HL 
calculus  provides  more  expressive  power  in  terms  of  the  kinds  of  modules  one  can  write,  but  it  is 
easier  to  track  separability  accurately  in  second-class  languages. 

Each  existing  dialect  treats  its  functors  as  being  either  always  separably  total  or  always  partial, 
with  the  exception  of  Shao’s  calculus,  which  recognizes  both  kinds  of  functors.  In  addition,  all  the 
dialects  support  either  the  basic  or  the  impure  form  of  sealing,  but  none  supports  both.  There  is 
no  particular  reason,  however,  why  a  module  language  could  not  support  both  forms  of  sealing. 

Among  the  dialects  in  which  total  functors  exist,  the  arguments  to  total  functors  are  compared 
in  Russo’s  and  Shao’s  languages  using  static  equivalence  and  in  O’Caml  using  syntactic  equivalence. 
While  the  super-system  indicates  that  static  equivalence  is  appropriate  when  comparing  arguments 
to  separably  total  functors,  the  O’Caml  semantics  has  the  effect  of  making  functors  behave  as  if 
they  were  statically  total  on  certain  common  kinds  of  arguments,  namely  SML-style  paths.  For 
functors  like  Set  that  we  would  like  to  treat  as  statically  total  for  purposes  of  data  abstraction, 
the  O’Caml  semantics  at  least  provides  something  closer  to  statically  total  behavior  than  the  other 
ML  dialects  do,  but  it  is  still  not  the  real  thing.  On  the  downside,  as  argued  in  Section  1.2.8, 
syntactic  equivalence  is  rather  brittle  in  the  sense  that  two  modules  will  be  deemed  inequivalent 
even  if  one  is  just  a  renaming  of  the  other  {e.g.,  structure  X  =  Y).  Furthermore,  for  functors 
that  the  programmer  wants  to  treat  as  separably  total,  syntactic  equivalence  is  an  unnecessarily 
conservative  way  of  comparing  their  arguments. 

2.2.2  A  Unifying  Design 

In  this  thesis  I  propose  a  new  dialect  of  ML  whose  module  system  design  is  based  closely  on  the 
super-system  set  forth  in  this  chapter.  This  section  sketches  the  high-level  design  of  the  language, 
with  comparisons  to  the  existing  designs.  The  following  section  gives  more  details  regarding  the 
structure  of  the  language  definition. 

Like  the  existing  ML  dialects,  my  new  design  avoids  the  need  for  dependent  types  by  assuming 
separability,  instead  of  static  purity,  as  a  precondition  for  projectibility.  Consequently,  like  Shao’s 
calculus,  my  language  distinguishes  between  separably  total  functors  and  partial  functors,  but  does 
not  recognize  the  intermediate  classification  of  statically  total  functors.  I  compare  arguments  to 
total  functors  using  full  static  equivalence  as  in  Shao’s  calculus,  because  it  is  less  conservative  than 
O’Caml’s  syntactic  equivalence  and  more  semantically  consistent  with  the  super-system.  Unlike 
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any  existing  dialect,  however,  my  language  gives  the  programmer  access  to  both  the  basic  and 
impure  forms  of  sealing,  each  of  which  we  have  seen  can  be  useful  in  different  circumstances.  It 
does  not  support  the  inseparable  form  of  sealing,  but  neither  does  any  existing  dialect. 

With  respect  to  the  flexibility  of  the  module  language,  my  new  design  combines  the  benefits  of 
first-class  and  second-class  module  systems.  It  is  structured  like  a  second-class  system  in  that  the 
language  of  module  expressions  is  kept  separate  from  that  of  core  ML  expressions.  It  differs  from 
existing  second-class  dialects,  though,  in  that  it  allows  one  to  express  impure/inseparable  modules 
as  well  as  separable  ones.  This  is  accomplished  by  providing  coercions  between  expressions  in  the 
module  and  core  languages.  In  particular,  I  introduce  a  new  “package  type”  (|SD,  which  is  used  to 
classify  a  module  of  signature  S  that  has  been  packaged  as  (i.e.,  coerced  to  the  level  of)  a  core¬ 
language  term.  Modules  are  coerced  into  the  term  level  by  a  pack  operation,  and  expressions  of 
package  type  are  coerced  back  to  the  module  level  by  an  unpack  operation. 

For  example,  the  module  expressions  Mgui  and  Mdict  defined  in  Sections  2.1.1  and  2.1.2  would 
be  encoded  in  my  type  system  as 

unpack(if  ...  then  (pack  LinkedList  as  SIG)  else  (pack  HashTable  as  SIG)) 

The  module  variables  LinkedList  and  HashTable  must  first  be  coerced  via  pack  operations  to  the 
common  package  type  (|SIGD,  where  SIG  is  an  opaque  signature  matched  by  both  implementations; 
then  the  result  of  the  core-level  conditional  expression  is  coerced  back  to  the  module  level  via 
unpacking.  Since  the  type  components  of  an  unpacked  module  expression  may  depend  on  the  result 
of  a  core-level  dynamic  computation,  I  conservatively  treat  all  unpacked  expressions  as  inseparable. 

This  hybrid  approach  offers  the  practical  benefits  of  second-class  systems  along  with  the  ex¬ 
pressive  power  of  first-class  systems.  It  provides  the  option  of  intermingling  module  and  core 
expressions  when  so  desired.  However,  compared  to  a  purely  first-class  language  like  Harper  and 
Lillibridge’s,  it  has  the  advantage  that  it  avoids  the  insinuation  of  module-level  subtyping  into  the 
core  ML  language,  and  it  enables  more  accurate  tracking  of  separability  for  strictly  second-class 
module  expressions  that  do  not  involve  unpacking. 

2.2.3  A  Modular  Design 

The  design  I  have  sketched  above  will  serve  as  the  basis  of  a  new  ML  dialect,  to  be  defined  formally 
in  Part  HI.  As  explained  in  the  Introduction,  I  define  this  new  dialect  in  the  style  of  Harper  and 
Stone  [33].  That  is,  the  programmable  “external”  language  (EL)  is  defined  by  an  “elaboration” 
translation  into  the  “internal”  language  (IL),  which  is  in  turn  defined  by  a  type  system.  In  the 
chapters  that  follow,  I  will  present  a  slightly  simplified  version  of  this  IL  type  system.  In  order  to 
make  the  meta-theory  a  bit  less  cumbersome,  I  will  omit  certain  inessential  details  of  the  full  IL, 
such  as  its  primitives  for  exception  handling  and  its  treatment  of  structure’s  as  labeled  (instead 
of  unlabeled)  records.  I  will  also  omit  the  extensions  relevant  to  recursive  modules,  which  will  be 
studied  in  Part  H,  but  all  the  other  key  features  of  the  language  remain.  In  addition,  I  will  give  a 
decidable  typechecking  algorithm  for  this  simplified  IL  that  scales  straightforwardly  to  handle  the 
full  IL  defined  in  Part  HI. 

As  explained  above,  the  IL  has  two  layers:  the  core  language  of  types  and  terms,  and  the 
module  language  of  signatures  and  modules.  In  existing  ML  dialects,  the  module  language  does 
not  merely  serve  as  a  means  of  “programming  in  the  large,”  it  also  adds  fundamental  expressive 
power  to  the  language.  For  instance,  while  the  core  language  of  Standard  ML  only  supports  prenex 
polymorphism,  one  can  encode  a  second-class  form  of  higher-kinded  and  rank-2  polymorphism  using 
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functors.  There  is  good  practical  justification  for  sharing  the  expressive  power  of  the  language 
in  this  way  between  the  core  and  module  languages,  namely  that  it  is  necessary  to  place  certain 
limitations  on  the  power  of  the  core  language  in  order  to  make  ML-style  type  inference  possible. 
At  the  level  of  the  explicitly-typed  internal  language,  however,  this  is  not  a  concern. 

Therefore,  in  the  interest  of  modularizing  the  design  of  the  internal  language,  I  have  structured 
its  type  system  in  such  a  way  that  all  the  expressive  power  of  the  language  is  contained  within 
the  core  language,  and  the  sole  purpose  of  the  module  language  is  to  provide  more  convenient 
mechanisms  for  structuring  core-language  code  and  enforcing  data  abstraction.  Organizing  the  IL 
in  this  way  means  that  the  type  structure  of  the  core  language  is  self-contained  and  the  module 
language  does  not  add  anything  to  it.  This  has  several  interesting  implications. 

First,  since  the  language  of  types  is  well-defined  independently  of  the  module  language,  there 
can  be  no  type  constructor  of  the  form  M.t!  Instead,  observe  that  M.t  is  only  a  sensible  type 
if  M  is  separable.  Separability  means  precisely  that  the  type  components  of  M  may  be  separated 
out  from  the  rest  of  the  module — there  is  no  way  they  can  really  depend  on  the  term  components. 
Correspondingly,  in  Chapter  4,  I  define  a  meta-level  function,  called  for  historical  reasons  Fst(M), 
that  computes  a  type  constructor  representing  the  “static  part”  of  M.  When  M  is  a  module 
variable  X,  Fst(M)  is  a  constructor  variable  which  I  take  to  represent  the  static  part  of  whatever 
module  will  instantiate  X.  For  other  module  expressions,  Fst(M)  is  definable  in  terms  of  the  existing 
type  structure  of  System  For  example,  when  M  is  a  structure,  Fst(M)  will  be  a  record  of  type 
constructors,  each  of  which  represents  the  static  part  of  one  of  M’s  components.  When  M  is  a  total 
functor,  Fst(M)  will  be  a  function  (at  the  level  of  type  constructors)  that  takes  as  input  the  static 
part  of  M’s  argument  and  returns  as  output  the  static  part  of  its  result. With  this  Fst  function 
in  hand,  we  can  replace  M.t  by  the  core-language  type  Fst(M)  .t,  which  projects  the  t  component 
from  the  record  of  types  Fst(M)  representing  M’s  static  part. 

Second,  when  building  the  module  language,  the  notion  of  static  module  equivalence  comes 
“for  free”  in  the  sense  that  it  is  definable  directly  in  terms  of  core-language  type  equivalence.  Two 
modules  Mi  and  M2  are  statically  equivalent  precisely  when  their  static  parts  Fst(Mi)  and  Fst(M2) 
are  equivalent  type  constructors.  Since  module  equivalence  is  only  needed  by  the  type  system  in 
order  to  define  type  equivalence,  it  makes  sense  that  the  core  language  should  have  it  built  in. 

Third,  just  as  the  static  parts  of  modules  are  expressible  in  the  core  language  of  type  construc¬ 
tors,  the  static  parts  of  signatures  are  correspondingly  expressible  in  the  core  language  of  kinds.  To 
compute  the  static  part  of  a  signature  S,  I  define  another  Fst  function,  this  time  mapping  signatures 
to  kinds,  which  satisfies  the  property  that  whenever  M  has  signature  S,  Fst(M)  has  kind  Fst(S)  as 
well.  The  definition  of  Fst  on  signatures  is  much  as  one  would  expect.  In  particular,  the  static 
part  of  a  structure  signature  is  a  record  kind  describing  the  static  part  of  each  component,  and 
the  static  part  of  a  total  functor  signature  is  an  arrow  kind.  If  signatures  only  contained  opaque 
type  specifications,  then  the  kind  structure  of  F^^  would  suffice.  But  how  do  we  faithfully  compute 
the  static  part  of  a  signature  like  sig  type  t  =  int  end?  That  is,  how  can  we  ensure  that  the 
resulting  kind  only  characterizes  the  static  parts  of  modules  whose  t  component  is  int? 

In  order  to  encode  such  transparent  specifications  in  the  kind  language,  I  employ  Stone  and 
Harper’s  “singleton”  kinds  [74].  Whereas  kinds  in  F^^  only  provide  structural  information  about  the 
constructors  that  inhabit  them,  kinds  in  the  singleton  calculus  can  provide  information  regarding 

Specifically,  higher-kinded  polymorphism  can  be  encoded  by  parameterizing  over  a  module  containing  a  type 
component  of  higher  kind,  and  rank-2  polymorphism  can  be  encoded  by  parameterizing  over  a  module  containing  a 
value  component  of  polymorphic  type. 

^^When  M  is  a  partial  functor,  it  has  no  static  part  because  its  body  is  potentially  inseparable.  Formally,  Fst(M) 
is  defined  to  be  the  trivial  unit  constructor. 
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the  identity  of  their  inhabitants.  For  a  type  C  of  base  kind  T,  the  singleton  calculus  allows  us  to  give 
it  the  more  precise  kind  5(C),  which  only  classifies  types  that  are  equivalent  to  C.  Consequently, 
when  processing  a  type  definition  like  type  t  =  C,  we  indicate  that  t  is  shorthand  for  C  by  binding 
it  in  the  context  with  kind  S(C). 

As  singleton  kinds  make  the  kind  language  dependent  on  the  constructor  language,  the  Stone- 
Harper  calculus  also  supports  dependent  product  and  arrow  kinds.  The  kind  Sq;:Ki.K2  classifies 
a  pair  of  type  constructors  with  kinds  Ki  and  K2,  where  K2  may  refer  to  the  first  component 
of  the  pair  via  the  constructor  variable  ol.  Similarly,  the  kind  nQ;:Ki.K2  classifies  a  constructor 
function  whose  result  kind  K2  may  depend  on  the  identity  of  the  argument  a.  For  instance,  the 
kind  nQ;:T.5(a)  uniquely  characterizes  the  identity  function  on  types. 

By  combining  dependent  kinds,  singleton  kinds,  and  the  standard  “opaque”  kind  T,  the  Stone- 
Harper  calculus  faithfully  models  the  flexibility  of  MB’s  translucent  signatures.  For  example,  the 
kind  SQ::T.5(int  X  a)  is  a  direct  analogue  of  the  signature  sig  type  t;  type  u  =  int  *  t  end. 
That  the  two  should  be  in  such  close  correspondence  is  no  coincidence.  The  Stone-Harper  calculus 
was  designed  as  a  target  of  type-directed  compilation  for  SML,  with  the  goal  of  preserving  the 
benefits  and  semantics  of  translucency  in  the  absence  of  modules. 

One  of  the  major  advantages  of  using  the  Stone-Harper  singleton  calculus  as  the  basis  of  the 
IL’s  core  language  is  that  it  isolates  the  meta-theoretic  complications  of  translucency  in  a  language 
that  has  been  well-studied.  Proving  that  type  equivalence  is  decidable  in  the  presence  of  singleton 
kinds  is  highly  non-trivial,  but  Stone  and  Harper  have  already  done  it.  By  modularizing  the  IL 
so  that  the  module  language  does  not  extend  the  type  structure  of  the  core  language,  I  am  able 
to  reuse  the  Stone-Harper  meta-theory  “off  the  shelf,”  so  to  speak,  greatly  easing  the  burden  of 
proving  module  typechecking  decidable. 

It  should  be  noted  that  organizing  the  IL  in  this  way  is  not  an  original  idea.  It  was  first 
propounded  by  Harper,  Mitchell  and  Moggi  in  their  “phase  distinction”  calculus  [30].  The  major 
difference  is  that  my  language  supports  the  modern  ML  features  of  translucency  and  sealing,  which 
theirs,  dating  back  to  1990,  does  not.  Correspondingly,  the  type  structure  of  their  core  language 
does  not  include  singleton  kinds.  In  addition,  they  treat  Fst(M)  as  a  primitive  type  constructor, 
albeit  one  that  is  always  reducible  to  some  module-free  core-language  constructor.  Treating  Fst(M) 
as  primitive,  however,  requires  them  to  build  a  whole  equational  theory  around  it.  My  approach  of 
defining  Fst  via  a  meta-level  macro  is  a  simpler,  more  lightweight  solution. 

Shao  [69],  in  his  type  system  for  modules,  employs  a  technique  similar  to  my  Fst  function  for 
extracting  the  static  parts  of  modules  and  signatures  (he  calls  it  the  “flexroot”  function).  His 
calculus  is  not  organized,  though,  in  the  fashion  that  I  have  advocated:  translucency  is  modeled  in 
his  calculus  directly  at  the  module  level,  not  through  the  kind  structure,  so  the  equational  theory 
of  types  is  dependent  on  the  module  language.  As  I  have  argued,  I  believe  my  approach  makes  the 
language  definition  more  elegant  and  modular. 

The  two  chapters  that  follow  give  the  formal  definition  of  the  (simplified)  IL,  Chapter  3  pre¬ 
senting  the  core  language  and  Chapter  4  the  module  language. 
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2.3  Comparison  With  a  Previous  Version  of  This  Account 

This  final  section  relates  the  work  of  this  chapter  to  an  earlier,  published  version  by  Dreyer,  Crary 
and  Harper  (hereafter,  DCH)  [12],  While  many  of  the  ideas  are  the  same,  the  present  account 
makes  a  more  refined  set  of  distinctions  than  DCH  does,  and  the  structure  of  the  IL  described  in 
the  previous  section  marks  a  significant  change  from  (and  simplification  of)  the  structure  of  the 
DCH  module  system.  There  are  also  some  unfortunate  clashes  of  terminology  between  the  two 
accounts  that  warrant  clarification. 

Conceptual  Comparison  The  most  important  conceptual  difference  between  the  two  accounts 
is  that  the  present  account  makes  a  distinction  between  the  properties  of  static  purity  and  separa¬ 
bility,  while  DCH  does  not.  Correspondingly,  DCH  only  observes  the  distinction  between  separably 
total  and  partial  functors,  and  only  recognizes  the  basic  and  impure  forms  of  sealing.  Although 
the  language  design  I  propose  in  this  thesis  suffers  from  precisely  the  same  limitations  as  the  DCH 
language,  I  have  attempted  to  make  it  clear  that  this  is  out  of  a  practical  necessity — avoiding 
dependent  types — rather  than  a  semantic  one.  By  starting  with  a  richer  set  of  module  classifica¬ 
tions  and  then  paring  it  down,  we  can  better  understand  what  exactly  the  ML  module  system  is 
missing — namely,  statically  total  functors  and  inseparable  sealing — and  why  it  is  missing  them. 

In  the  absence  of  a  distinction  between  purity  and  separability,  my  present  account  recognizes 
three  module  classifications:  projectible  (and  hence  separable),  separable  but  not  projectible,  and 
inseparable  (and  hence  not  projectible).  DCH  makes  precisely  these  classifications  as  well,  although 
it  describes  their  genesis  in  a  rather  different  way.  (Actually,  DCH  makes  a  fourth  classification, 
but  as  I  explain  below  it  is  essentially  superfluous.) 

The  basic  tenet  of  DCH  is  that  a  module  is  projectible  if  and  only  if  it  is  pure,  where  the  term 
“pure”  means  something  other  than  what  I  have  to  taken  it  to  mean  in  this  chapter.  DCH  considers 
a  module  expression  to  be  pure  if  it  is  free  of  certain  “effects”  that  result  in  the  creation  of  new 
types.  There  are  two  kinds  of  such  effects,  which  DCH  terms  “dynamic”  and  “static.” 

Dynamic  effects  are  ordinary  computational  (run-time)  effects  that  affect  the  identities  of  a 
module’s  type  components,  such  as  the  call  to  buttonIsSelected  in  the  module  expression  Mgui 
from  Section  2.1.1.  Dynamic  effects  are  also  induced,  notionally,  by  sealing  a  module  using  impure 
sealing,  which  DCH  refers  to  as  “strong”  sealing.  Despite  the  use  of  the  word  “effect,”  there  are 
modules  that  are  computationally  pure,  such  as  Mdict  from  Section  2.1.2,  that  DCH  considers 
to  be  dynamically  impure.  In  short,  the  meaning  of  “dynamically  impure”  in  DCH  corresponds 
directly  in  the  present  account  to  “inseparable  and  possibly  impure.”  One  of  the  chief  advances  of 
the  present  account  over  DCH  is  the  observation  that  there  is  an  important  semantic  distinction  to 
be  made  between  truly  impure  modules,  like  MguI;  and  pure  but  inseparable  modules,  like  Mdigt- 

Static  effects,  on  the  other  hand,  are  induced  by  sealing,  both  by  the  impure  form  and  by  the 
basic  form,  which  DCH  calls  “weak”  sealing.  One  can  think  of  static  effects  as  occurring  at  compile 
time  instead  of  at  run  time  (hence  the  name  static).  For  this  reason,  while  static  effects  do  render  a 
module  non-projectible,  they  are  permitted  to  occur  in  the  body  of  a  total  functor  because  totality 
is  only  a  property  of  the  functor’s  dynamic  behavior.  In  the  present  account,  I  have  moved  away 
from  any  discussion  of  static  effects.  I  now  simply  point  out  that  data  abstraction  requires  all 
modules  that  contain  sealing  to  be  treated  as  non-projectible  (unless  they  are  transparent).  Since 
sealing  a  module  using  weak/basic  sealing  does  not  result  in  any  loss  of  information  about  its 
separability,  it  is  fine  for  a  separable,  weakly  sealed  module  to  appear  inside  a  total  functor. 

^■^Do  not  confuse  DCH’s  static  and  dynamic  effects  with  the  notions  of  static  and  dynamic  (im-)purity  set  forth  in 
this  chapter — they  mean  completely  different  things!  Apologies  for  any  headaches  this  may  cause. 
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DCH 

Classification 

in  the  Present  Account 

Dynamic  effects? 

Static  effects? 

no 

no 

separable  and  projectible 

no 

yes 

separable,  but  not  projectible 

yes 

yes 

inseparable,  and  thus  not  projectible 

yes 

no 

?? 

Figure  2.5:  Correspondence  Between  Classifications  in  DCH  and  in  This  Chapter 


DCH  classifies  module  expressions  based  on  whether  they  engender  both,  one  or  neither  kind 
of  effect.  This  results  in  four  module  classifications,  three  of  which  correspond  directly  to  the 
classifications  of  the  present  account.  These  correspondences  are  shown  in  Figure  2.5.  The  fourth 
classification,  which  DCH  denotes  with  the  purity  classification  of  S  (for  “Statically  pure,  but 
dynamically  effectful”),  is  an  odd  one.  Modules  that  have  dynamic  effects  in  DCH  are  inseparable 
and  must  therefore  be  non-projectible,  so  what  does  it  matter  whether  or  not  they  have  static 
effects?  Indeed  it  does  not,  and  I  claim  this  classification  is  essentially  superfluous.  It  was  only 
included  due  to  a  technicality,  for  more  discussion  of  which  see  footnote  9  in  Section  4.2.2. 

Structural  Comparison  The  type  system  of  DCH  is  structured  in  the  style  of  traditional  type- 
theoretic  accounts  of  ML  modules  (excepting  Harper,  Mitchell  and  Moggi’s)  in  the  sense  that 
the  module  language  and  the  type  structure  of  the  core  language  are  mutually  dependent.  In 
addition,  there  is  an  explicit  judgment  of  module  equivalence,  which  is  not  definable  in  terms 
of  type  equivalence.  DCH  is  similar  to  my  present  approach  (outlined  in  Section  2.2.3)  in  that  it 
employs  singletons  to  model  translucency,  but  instead  of  singleton  kinds  it  uses  singleton  signatures. 
The  singleton  signature  5s  (M)  classifies  modules  of  signature  S  that  are  (statically)  equivalent  to 
M.  Under  my  present  approach,  singleton  signatures  are  definable  using  singleton  kinds,  whereas 
in  DCH  they  are  primitive. 

There  are  two  main  reasons  why  I  prefer  the  present  organization  to  that  of  DCH.  The  first  is 
that  lifting  singletons  to  the  signature  level  requires  one  to  reprove  much  of  the  Stone-Harper  meta¬ 
theory  in  the  context  of  the  module  language.  While  not  fundamentally  difficult,  it  is  nonetheless 
painstaking  work.  It  is  much  simpler  to  use  the  existing  Stone-Harper  type  system  as  is. 

The  second,  more  subtle  reason  concerns  language  extensions.  Particularly  in  the  context  of 
recursive  modules,  one  would  like  to  add  features  to  the  module  language  that  offer  new  functionality 
but  do  not  alter  the  type  structure  of  the  language.  Under  the  DCH  approach,  any  change  to  the 
module  language  requires  one  to  go  through  carefully  and  check  that  the  new  cases  do  not  adversely 
affect  the  rather  complex  proof  of  decidability  of  type  equivalence.  Under  my  present  approach, 
so  long  as  the  “static  parts”  of  any  new  module  and  signature  constructs  are  definable  in  terms  of 
the  existing  type  structure,  no  theorems  regarding  decidability  of  type  equivalence  will  need  to  be 
extended  or  re-examined. 

One  respect  in  which  the  type  system  I  present  in  the  following  chapters  is  not  as  flexible  as 
DCH’s  is  that  I  employ  a  somewhat  more  restrictive  definition  of  subtyping  for  functors.  The 
specific  ways  in  which  it  is  more  restrictive  are  detailed  in  Section  4.1.2,  and  the  reasons  for  these 
restrictions  are  explained  in  Section  4.1.4.  This  does  not,  however,  amount  to  any  fundamental 
expressiveness  gap;  for  any  signatures  that  DCH  considers  to  be  in  a  subtyping  relationship,  that 
relationship  may  be  witnessed  in  my  present  type  system  by  an  explicit  module  coercion,  which 
the  elaboration  algorithm  I  define  in  Chapter  9  infers  automatically. 


Chapter  3 

A  Type  System  for  ML  Modules: 
Core  Language 


In  this  chapter,  I  will  present  the  core  language  of  my  type  system  for  ML  modules.  As  described  in 
Section  2.2.3,  I  have  lifted  my  core  language  almost  entirely  from  the  work  of  Stone  and  Harper  [74] 
(and  also  Stone’s  thesis  [72])  on  a  calculus  of  singleton  kinds.  This  chapter  will  therefore  be  to  a 
large  extent  a  review  of  Stone  and  Harper’s  calculus  and  its  meta-theoretic  properties,  intended 
mainly  for  the  reader  who  is  not  familiar  with  their  work. 

In  Section  3.1,  I  will  present  the  type  structure  of  the  core  language,  i.e.,  the  language  of  type 
constructors  and  kinds,  and  describe  the  Stone-Harper  algorithm  for  deciding  equivalence  of  type 
constructors  in  the  presence  of  singleton  kinds.  In  Section  3.2,  I  will  present  the  term  structure  of 
the  core  language  and  give  a  type  checking  algorithm  and  dynamic  semantics  for  terms. 

3.1  Type  Constructors  and  Kinds 

3.1.1  Syntax 

The  syntax  of  type  constructors  and  kinds  is  given  in  Figure  3.1.  The  language  of  type  constructors 
(represented  by  the  metavariable  C)  is  a  completely  standard  variant  of  Fi_j}  It  contains  a  set  of 
base  types  b — in  particular,  unit,  product,  arrow,  universal  and  existential  types — as  well  as  unit, 
pairing  and  function  operators  (and  corresponding  elimination  forms)  for  building  type  constructors 
of  higher  kind.  Constructor  variables,  written  a,  are  drawn  from  some  countably  infinite  set 
ConVars.  Although  a  let  construct  is  not  included  as  primitive,  it  is  easily  encodable.  I  will 
sometimes  write  “let  a  =  Ci  in  C2”  as  shorthand  for  7r2(a  =  Ci,  02).^ 

A  word  about  variable  bindings:  Throughout  this  thesis,  I  employ  the  standard  technique 
of  syntactically  identifying  any  two  expressions  that  differ  only  in  their  choice  of  bound  variable 
names.  Unless  otherwise  specified,  all  the  binding  constructs  I  use  look  like  “(x  =  61,62)”,  “let  x  = 
61  in  62”,  or  “x:6i.62”,  where  x  is  some  variable  (be  it  constructor,  term  or  module  variable),  and 
the  6’s  are  syntactic  expressions  of  some  form  (be  they  kinds,  constructors,  etc.).  In  all  of  these 

^The  expressive  power  of  ML  only  requires  us  to  use  the  predicative  form  of  iT  [61],  but  I  have  chosen  for  simplicity 
to  make  this  language  impredicative. 

^The  Stone-Harper  calculus  only  provides  a  pair  construct  of  the  form  (Ci,C2).  The  one  I  employ  here,  which 
binds  a  to  Ci  inside  C2,  is  not  strictly  necessary,  but  I  have  found  it  to  be  rather  convenient.  In  Dreyer  et  al.  [11] 
I  verified  that  Stone  and  Harper’s  meta-theory  is  essentially  unchanged  when  one  allows  this  variant  of  the  pair 
construct.  In  a  similar  vein.  Stone  and  Harper  do  not  include  a  unit  kind  either,  but  supporting  it  requires  only  a 
trivial  and  obvious  extension  to  their  meta-theory  (again  verified  in  Dreyer  et  al.  [11]). 
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Constructor  Variables 

a 

(3  G 

Con  Vars 

Kinds 

K 

L  :;  = 

1 

T  1  5(C)  1 

Sa;Ki 

.K2 

1  na:Ki.K2 

Transparent  Kinds 

K 

L  ::= 

1 

5(C)  1  Sa; 

Ki  .IK2 

1  nQ;:Ki.IC2 

Type  Constructors 

c. 

D  ;:= 

a 

IH  ()!(«  = 

=  Cl,C2)  1 

TTiC  1  Aa:K.C  |  Ci(C2) 

Base  Types 

b  ::= 

unit  Cl  X  C2 

|Ci- 

>C2 

1  Va:K.C  |  3a:K.C 

Static  Contexts 

A  ::= 

0 

A,a:K 

Figure  3.1;  Syntax  of  Type  Constructors  and  Kinds 


cases,  X  is  assumed  to  be  bound  in  62-  Thus,  for  example:  In  the  pair  constructor  (a  =  Ci,C2), 
the  variable  a  stands  for  the  constructor  Ci  inside  02-  In  the  function  constructor  AarK.C,  the 
argument  variable  a,  whose  kind  is  K,  is  bound  in  the  body  C.  In  addition,  I  will  use  the  notation 
e[ei,  •  •  • ,  Cn/xi,  •  •  • ,  Xn]  to  denote  the  simultaneous  capture-avoiding  substitution  of  ei,  •  •  • ,  for 
xi,  •  •  • ,  Xn,  respectively,  in  e. 

Now  for  the  interesting  part:  the  kind  language.  Let  us  look  at  the  different  kind  forms  one  at 
a  time.  The  unit  kind  1  classifies  only  one  type  constructor,  namely  the  unit  constructor  (),  not 
to  be  confused  with  the  base  type  unit.  The  base  kind  T,  which  in  many  presentations  of  F^j  is 
written  as  *  or  Ll,  classifies  those  types  which  themselves  classify  terms.  In  a  closed  program,  every 
type  constructor  of  base  kind  will  be  reducible  to  a  syntactic  base  type  b. 

The  other  base  kind  is  the  singleton  kind  S(C),  a  subkind  of  T  that  classifies  precisely  those 
type  constructors  that  are  equivalent  to  C.  As  explained  in  Section  2.2.3,  singletons  allow  one  to 
support  a  notion  of  “type  definition”  within  a  regular  kind  structure.  Furthermore,  the  combination 
of  the  “opaque”  base  kind  T  and  the  “transparent”  singleton  kind  5(C)  provide  a  natural  basis  for 
translucent  signatures  in  the  module  language. 

The  dependent  pair  kind  Sa:Ki.K2  classifies  pairs  of  constructors  whose  first  component  has 
kind  Ki  and  whose  second  component  has  kind  K2,  where  a  stands  for  the  first  component.  In 
other  words,  a  constructor  C  has  kind  Sq;:Ki.K2  if  and  only  if  ttiC  has  kind  Ki  and  7r2C  has  kind 
K2[vriC/a].  When  the  bound  variable  a  does  not  appear  free  in  K2,  I  will  sometimes  write  the  pair 
kind  as  Ki  x  K2. 

The  dependent  arrow  kind  nQ;:Ki.K2  classifies  constructor  functions  that  take  an  argument  of 
kind  Ki  and  return  a  result  of  kind  K2,  where  a  stands  for  the  argument.  Thus,  a  constructor  C 
has  kind  na;Ki.K2  if  and  only  if,  whenever  D  has  kind  Ki,  C(D)  has  kind  K2[D/a].  When  the 
bound  variable  a  does  not  appear  free  in  K2,  I  will  sometimes  write  the  arrow  kind  as  Ki  — >K2. 

While  the  primitive  singleton  kind  5(C)  is  only  valid  when  C  has  kind  T,  singletons  at  higher 
kind  are  in  fact  definable  in  terms  of  the  primitive  kinds.  Figure  3.2  defines  a  meta-level  function 
5k  (C),  which  returns  a  subkind  of  K  classifying  precisely  those  constructors  that  are  equivalent 
to  C  (assuming  C  actually  has  kind  K).^  At  the  base  kinds  T  and  5(D),  5k(C)  is  defined  as  just 
the  primitive  singleton  5(C).  The  definition  of  5k(C)  at  the  remaining  kinds  reflects  the  fact  that 
constructor  equivalence  in  the  Stone-Harper  calculus  is  extensional,  i.e.,  if  two  constructors  are 
impossible  to  distinguish  by  their  uses  then  they  are  as  good  as  equivalent.  Specifically,  if  we  read 
D’s  membership  in  5k (C)  as  “D  is  equivalent  to  C  at  kind  K,”  then  we  see  from  the  definition 
of  5k(C)  that  (1)  D  is  equivalent  to  C  at  pair  kind  when  ttiD  is  equivalent  to  ttiC  and  7r2D  is 
equivalent  to  7r2C,  (2)  D  is  equivalent  to  C  at  arrow  kind  when  D(q;)  is  equivalent  to  C(a),  and  (3) 

®The  function  5k(C)  is  defined  inductively  on  the  size  of  the  kind  K  using  the  size  metric  given  in  Definition  3.1.6. 
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5i(C) 

5t(C) 

•®5{d)(C) 

•5Sa:Ki.K2(C) 

•5na:Ki.K2(C) 


=  S(C) 

=  S(C) 

=  SKi(7riC)  X  SK2[7riCH(’’'2C) 
=  na:Ki.SK2(C(a)) 


Figure  3.2;  Singletons  at  Higher  Kinds 


Can(l) 

Can(S(C)) 

Can(SQ;:]Ki.K2) 

Can(nQ;:Ki.IK2) 


=  0 
=  c 

(a  =  Can(Ki),Can(K2)) 
=  Aa:Ki.Can(IC2) 


Figure  3.3:  Canonical  Constructors  of  Transparent  Kinds 


all  constructors  of  unit  kind  are  equivalent  because  they  are  all  equally  useless. 

The  definition  of  higher-order  singletons  given  in  Figure  3.2  is  not  the  only  possible  one.  For  in¬ 
stance,  •50(j3)(C)  and5sa:Ki.K2(C)  could  just  as  well  be  defined  as  5(D)  and  Sa:SKi(7riC).SK2('^2C), 
respectively.  It  is  also  likely  possible  to  make  Sk(C)  a  primitive  kind  instead  of  a  macro,  and  to 
build  in  the  definitional  equations  in  Figure  3.2  as  kind  equivalence  rules.  This  would  have  the 
slight  disadvantage,  however,  of  losing  the  property  that  kind  equivalence  and  subtyping  (discussed 
below)  are  syntax-directed.  For  simplicity,  I  have  avoided  any  complications  by  defining  5k(C) 
precisely  as  Stone  and  Harper  do. 

Higher-order  singletons  are  a  special  case  of  a  more  general  subclass  of  kinds  that  I  call  “trans¬ 
parent”  and  denote  by  the  metavariable  K.  The  syntax  of  transparent  kinds,  given  in  Figure  3.1, 
requires  essentially  that  no  instances  of  the  opaque  base  kind  T  appear  on  the  right-hand  side  of  an 
arrow.  A  transparent  kind  K  has  the  property  that  any  two  constructors  of  kind  IC  are  equivalent, 
and  in  fact  transparent  kinds  are  the  only  kinds  to  enjoy  this  property.  Consequently,  given  any 
transparent  kind  K,  Figure  3.3  shows  how  to  construct  a  “canonical”  constructor  Can(IK)  of  kind 
K,  which  is  guaranteed  to  be  equivalent  to  any  other  inhabitant  of  K.  Transparent  kinds  will  be 
needed  primarily  in  order  to  define  a  notion  of  transparent  signatures  in  Chapter  4. 

Finally,  I  define  a  notion  of  static  contexts,  written  A,  which  bind  constructor  variables  to  their 
kinds.  I  call  these  contexts  static  so  as  to  distinguish  them  from  dynamic  contexts  F  that  also 
bind  value  and  module  variables.  For  all  forms  of  contexts,  I  require  that  all  variables  bound  in  a 
context  be  distinct  in  order  for  the  context  to  be  syntactically  valid.  I  will  also  sometimes  treat  a 
context  as  a  (meta-level)  function  from  variables  to  classifiers,  e.g.,  if  q;:K  G  A,  then  A(q;)  =  K. 

3.1.2  Static  Semantics 

Figure  3.4  shows  the  inference  rules  for  the  judgments  of  well-formed  contexts,  well-formed  kinds, 
kind  equivalence  and  kind  sub  typing.  The  rules  for  the  first  three  of  these  judgments  are  fairly 
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Well- formed  static  contexts:  A  h  ok 


h  ok 


(1) 


A  h  K  kind 
A,  a:K  h  ok 


(2) 


Well-formed  kinds:  A  h  K  kind 


A  h  ok 
A  h  1  kind 


(3) 


A  h  ok 
A  h  T  kind 


(4) 


A  h  C  :  T 
A  h  S(C)  kind 


(5) 


A,  q;:K'  h  K"  kind 
A  h  SaiK'.K"  kind 


(6) 


A,  a:K'  h  K"  kind 
A  h  naiK'.K"  kind 


(7) 


Kind  equivalence:  A  h  Ki  =  K2 


A  h  ok  /gx 

A  h  1  =  1 


A  h  p) 


A  h  K;  =  K'2  A,  a:K;  h  K'/  =  K" 


A  h  Ea:K[.K'(  =  SaiK^.K; 


A  h  T  =  T 

2  (11) 


A  h  Cl  =  C2  ;  T 
AhS(Ci)  =S(C2) 


(10) 


A  h  K'2  =  K[  A,  a:K^  h  K'/  =  K" 


A  h  na:K;.K;'  =  naiK^.K: 


(12) 


Kind  subtyping:  A  h  Ki  <  K2 


A  h  ok 


(13) 


A  h  ok 


(14) 


A  h  Cl  =  C2  ;  T 


(15) 


A  h  C  :  T 


Ahl  AhT<T'"'  A  hS(Ci)  <S(C2)  '  '  AhS(C)<T 

A  h  K;  <  K'2  A,  a:K;  h  K'/  <  K^'  Ah  SaiK^.K^'  kind 


(16) 


A  h  Ea:K[.K'(  <  Sa:K'2.K" 

A  h  K'2  <  K;  a,  a:K'2  h  K'/  <  K^'  Ah  HaiK'^.K'/  kind 


A  h  na:K;.K'/  <  na:K'2.K'2' 


(17) 

(18) 


Figure  3.4;  Inference  Rules  for  Kinds  and  Static  Contexts 


obvious.  The  only  point  of  note  is  that,  following  Stone-Harper,  for  any  derivation  of  a  judgment 
of  the  form  A  h  77,  the  static  semantics  ensures  that  the  well-formedness  of  the  context  (A  h  ok) 
appears  as  a  sub  derivation.  This  explains,  for  instance,  why  there  is  no  need  for  extra  premises 
A  h  ok  and  A  h  K'  kind  in  Rules  2  and  7,  respectively. 

The  rules  for  kind  subtyping  are  also  fairly  straightforward.  For  base  kinds,  subtyping  is  just 
equivalence  with  the  addition  of  Rule  16.  This  rule  allows  one  to  coerce  a  constructor  from  the 
transparent  base  kind  S(C)  to  the  opaque  base  kind  T,  thereby  forgetting  that  the  constructor  is 
equivalent  to  C.  The  remaining  rules  lift  this  forgetful  subtyping  to  higher  kinds,  in  the  standard 
CO-  and  contra-variant  manner.  The  only  point  of  note  here  is  that,  in  Rules  17  and  18,  the  third 
premise  is  included  in  order  to  ensure  Validity  (Proposition  3.1.8  below). 

Figure  3.5  shows  the  inference  rules  for  the  judgments  of  well-formed  constructors  and  con¬ 
structor  equivalence.  Concerning  the  former,  most  of  the  rules  are  completely  standard  for  a 
dependently-typed  calculus.  The  three  rules  that  merit  special  attention  are  Rules  31-33.  Taken 
together,  these  rules  enable  any  type  constructor  C  to  be  given  a  most-specific  transparent  kind 
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Well-formed  constructors:  A  h  C  :  K 


A  h  ok  a:K  €  A 
A  h  a  :  K 


A  h  ok 

A  h  unit  :  T 


A  h  C'  :  T  A  h  C"  :  T 


A  h  C'  X  C"  ;  T 


AhC^T  AhC^':T  ...x  A,a:KhC:T  A,a:KhC  :  T 

A  h  C'  ^  C"  ;  T  ^  ^  Ah  Va:K.C  :  T  ^  ^  A  h  3a:K.C  :  T  ^  ’ 


A  h  ok 
A  h  0  :  1 


A  h  C'  :  K'  A,  a:K'  h  C"  :  K" 

A  h  {a  =  C',C")  :  SmK'.K" 

A,  a:K'  h  C  :  K" 


A  h  C  :  Sa:KhK'^  .271  A  h  C  :  .281 

A  h  TTiC  :  K'  ^  ’  A  h  TTsC  :  K"[7riC/a]  ^  ’ 


A  h  AaiK'.C  :  Ua:K' .K" 


A  h  C  :  na:KhK^'  A  h  D  :  K'  .o^x 

A  u  r’/'TA^  .  '  > 


A  h  C  :  T  .o.x  A  h  V 
A  h  C  :  S(C)  ^  ’ 

A,  a:K'  h  C(a)  :  K"  A  h  C  :  HaiKhL 
A  h  C  :  naiK'.K" 


A  h  C(D)  :  K"[D/a\ 

A  h  TTiC  :  K'  Ah  vrsC  :  K" 
A  h  C  :  K'  X  K" 


Constructor  equivalence:  A  h  Ci  =  C2  :  K 


A  h  C  :  K 
A  h  C  =  C  :  K 


A  h  C2  =  Cl  :  K 
A  h  Cl  =  C2  :  K 


AhC:K'  AhK'<K 
A  h  C  :  K 


A  h  Cl  =  C2  ;  K  A  h  C2  =  C3  :  K 


A  h  Cl  =  C3  :  K 


A  h  C'l  =  C'o  :  T  A  h  C'/  =  Ci'  :  T  ,  ,  A  h  C',  =  Ci  :  T  Ah  C'/  =  Ci'  :  T  ,  , 
A  h  C;  X  C'{  =  C^  X  C^'  ;  T  A  h  C'^  ^  C'/  =  C'2  ^  C^'  :  T 

AhKi  =  K2  A,a:KihCi  =  C2:T  A  h  Ki  =  K2  A,  a:Ki  h  Ci  =  C2  :  T 

A  W„,.TV  C  —  W„,.TV_  .  T-I  A  ZI„,.T^  C  —  ZI„,.T^_  C  _  .  Ti 


A  h  VaiKi.Ci  =  Va:K2.C2  :  T  '  '  A  h  3a:Ki.Ci  =  3a:K2.C2  :  T 

A  h  C;  =  C'2  ;  K'  A,  a:K'  h  C'/  =  C'2'  ;  K" 

A  h  (a  =  C'i,C;')  =  (a  =  C'2,C^')  :  SmK'.K" 

A  h  Cl  =  C2  :  Sa:K'.K"  ,,,,  A  h  Ci  =  C2  :  Sa:K'.K" 


A  h  Cl  =  C2  :  Sa:K'.K" 

A  h  TTiCi  =  7riC2  :  K'  ^  ^ 

A  h  K;  =  K'  A,  a-.K[  h  Ci  =  C2  :  K" 

A  h  Aa:K'i.Ci  =  Aa:K^.C2  :  naiK'^.K"  ^  ’ 

AhCi:l  AhC2:l 
A  h  Cl  =  C2  :  1  ^  ^ 


A  h  7r2Ci  =  7r2C2  :  K"[7riCi/a]  '  ' 

A  h  Cl  =  C2  ;  na:K'.K"  A  h  Di  =  D2  ;  K' 
AhCi(Di)  =  C2(D2)  :K"[Di/a] 

AhCi:5(C)  AhC2:S(C) 

AhCi  =  C2:S(C)  ^  ’ 


A  h  TTiCi  =  7riC2  :  K'  Ah  7r2Ci  =  7r2C2  :  K" 

A  h  Cl  =  C2  :  K'  X  K"  ^  ^ 

A,  a:K'  h  Ci(a)  =  C2(a)  :  K"  A  h  Ci  :  naiK'.Li  A  h  C2  :  HaiK'.Ls 

A  h  Cl  =  C2  :  naiK'.K" 

AhCi  =  C2:K'  AhK'<K 
A  h  Cl  =  C2  ;  K 


Figure  3.5;  Inference  Rules  for  Type  Constructors 
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whose  only  inhabitant  is  C.  This  is  often  referred  to  as  “selfification.”  Perhaps  the  easiest  way  to 
read  the  rules  is  to  observe  how  they  allow  one  to  assign  to  any  constructor  C  the  transparent  kind 
Sk(C),  given  that  C  has  kind  K  to  begin  with.  While  it  is  possible  that  one  could  simply  replace 
Rules  31-33  with  one  rule  involving  higher-order  singletons,  I  have  chosen  as  before  to  follow  Stone 
and  Harper’s  presentation. 

As  for  constructor  equivalence:  Rules  35-37  establish  that  it  is  an  equivalence  relation,  a  prop¬ 
erty  that  is  admissible  for  kinds  but  must  be  made  explicit  for  constructors.  Rules  38-46  establish 
that  constructor  equivalence  is  a  congruence,  i.e.,  constructors  that  are  structurally  similar  and 
whose  component  parts  are  equivalent  are  themselves  equivalent.  Rules  47-48  exhibit  that  all  in¬ 
habitants  of  unit  kind  1  are  equivalent  (to  ()),  and  similarly  all  inhabitants  of  a  singleton  kind 
S(C)  are  equivalent  (to  C).  Rules  49-50  ensure  that  equivalence  is  extensional,  as  discussed  in  the 
previous  section.  The  extra  premises  in  Rule  50  ensure  that  a  is  not  free  in  Ci  and  C2.  Finally, 
Rule  51  enables  subsumption  for  the  constructor  equivalence  judgment. 

R  is  easy  to  see  that  constructor  equivalence  in  this  calculus,  unlike  constructor  equivalence  in 
System  is  highly  dependent  on  the  context  in  which  constructors  are  compared.  In  two 
distinct  constructor  variables  a  and  f3  will  never  be  considered  equivalent,  whereas  in  the  presence 
of  singletons  a  and  (3  may  very  well  be  equivalent  if,  say,  they  are  both  bound  in  the  context  with 
kind  S(C).  What  is  perhaps  less  obvious  is  that  the  equivalence  of  two  constructors  also  depends 
on  the  kind  at  which  they  are  compared,  that  is,  Ci  and  C2  may  be  equivalent  at  one  kind  but 
not  another.  The  canonical  example  of  this  is  when  Ci  =  \a:T.a  and  C2  =  AaiT.unit.  When  Ci 
and  C2  are  compared  at  T  ^  T,  they  are  not  considered  equivalent,  as  they  give  different  results 
when  applied  to  any  type  other  than  unit.  However,  when  compared  at  the  superkind  S(unit)  ^  T, 
they  are  indeed  extensionally  equivalent:  the  only  valid  argument  to  a  function  of  this  super  kind 
is  unit,  for  which  Ci  and  C2  return  equivalent  results.  As  a  consequence,  the  algorithm  presented 
in  Section  3.1.7  for  deciding  constructor  equivalence  is  both  kind-  and  context-sensitive. 

Lastly,  the  reader  may  have  noticed  that  the  equivalence  rules  do  not  include  any  standard 
f3-  or  77-equivalence  rules.  This  is  because  these  rules  are  admissible  in  the  presence  of  singletons 
and  extensional  equivalence.  In  the  case  of  /3-equivalence,  this  is  easy  to  see  by  example.  Suppose 
that  C  and  D  are  constructors  of  kind  T.  Then,  Aq;:T.C  can  be  given  kind  na:T.S(C).  The 
application  rule  (Rule  30)  tells  us  then  that  (Aa:T.C)(D)  has  kind  S(C[D/a])  and  is  therefore 
equal  to  C[D/a].  This  reasoning  lifts  easily  to  constructors  of  higher  kind  (see  Proposition  3.1.13). 
As  for  77-equivalence,  it  is  essentially  just  another  way  of  phrasing  the  concept  of  extensionality. 

3.1.3  Basic  Structural  Properties 

In  this  section  I  state  several  basic  structural  properties  concerning  the  language  of  constructors  and 
kinds  described  above.  Throughout  I  will  write  A  h  77  to  denote  any  judgment  with  right  hand  side 
77,  and  FV (77)  to  denote  the  set  of  variables  that  appear  free  in  one  or  more  syntactic  components 
of  77.  In  addition,  I  use  the  “=”  sign  to  indicate  syntactic  equality  (modulo  a-equivalence) . 

Proposition  3.1.1  (Subderivations) 

1.  Every  proof  of  A  h  77  contains  a  subderivation  of  A  h  ok. 

2.  Every  proof  of  Ai,q;:K,  A2  b  77  contains  a  strict  subderivation  of  Ai  h  K  kind. 

Proposition  3.1.2  (Free  Variable  Containment) 

If  A  h  77,  then  EV(77)  C  dom(A). 
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•  A'  h  7  :  A  iff 

1.  A'hok 

2.  Va:K  G  dom(A).  A'  h  7(a)  :  7(K) 

•  A'  h  7i  =  72  :  A  iff 

1.  A'  h  7i  :  A  and  A'  h  72  :  A 

2.  Va:K  G  dom(A).  A'  h  71(a)  =  72(a)  :  71  (K) 

Figure  3.6:  Typing  and  Equivalence  Judgments  for  Static  Substitutions 


Definition  3.1.3  (Context  Extension) 

The  context  A2  is  defined  to  extend  the  context  Ai  (written  A2  2  Ai)  if  the  contexts  viewed  as 
partial  functions  give  the  same  result  for  every  variable  bound  in  dom(Ai).  (Note  that  this  is  a 
purely  syntactic  condition  and  does  not  imply  that  either  context  is  well- formed.) 


Proposition  3.1.4  (Weakening) 

1.  If  Ai  h  J7,  A2  A  Ai,  and  A2  H  ok,  then  A2  F  J7. 

2.  If  Ai,  a:K2,  A2  h  J7,  Ai  h  Ki  <  K2  and  Ai  h  Ki  kind,  then  Ai,  a:Ki,  A2  F  J7. 

Static  substitutions  7  are  defined  as  maps  from  constructor  variables  to  constructors,  which  may 
be  applied  (in  the  usual  capture-avoiding  manner)  to  arbitrary  syntactic  expressions.  We  denote 
the  identity  substitution  as  id  and  substitution  extension  as  7[ai— >C].  Figure  3.6  defines  typing 
and  equivalence  judgments  for  substitutions. 


Proposition  3.1.5  (Substitution) 

1.  If  A  F  and  A'  F  7  :  A,  then  A'  F  ^{J). 

2.  If  Ai,a:K,A2  F  and  Ai  F  C  :  K,  then  Ai,A2[C/a]  F  J[C/a\. 

3.1.4  Other  Declarative  Properties 

In  this  section  I  state  several  other  useful  declarative  properties,  the  most  important  being  Validity 
and  Functionality.  Validity  ensures  that  all  constructors  or  kinds  mentioned  inside  a  derivable 
judgment  are  well-formed.  Functionality  ensures  that  applying  equivalent  substitutions  to  two 
sides  of  a  =  or  <  judgment  does  not  affect  the  derivability  of  the  judgment.  I  also  establish  that 
kind  equivalence  is  an  equivalence  relation  and  kind  subtyping  is  a  partial  order. 

First,  it  is  useful  for  purposes  of  induction  to  have  a  measure  of  the  “size”  of  a  kind  that  is 
invariant  under  substitution,  i.e.,  such  that  size(K)  =  size(7K)  for  any  7  and  K. 
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Definition  3.1.6  (Sizes  of  Kinds) 

Let  the  size  of  a  kind  K,  written  size(K),  be  defined  inductively  as  follows; 


size(l) 

def 

1 

size(T) 

def 

1 

size(S(C)) 

def 

2 

size(Sa;Ki.K2) 

def 

1  -|-  size(Ki) 

-1-  size(K2) 

size(na;Ki.K2) 

def 

1  -|-  size(Ki) 

-1-  size(K2) 

Proposition  3.1.7  (Refiexivity) 

If  A  h  K  kind,  then  A  h  K  =  K  and  A  h  K 

VI 

Proposition  3.1.8  (Validity) 

1.  If  A  h  Ki  =  K2,  then  A  h  Ki  kind  and  A  h  K2  kind. 

2.  If  A  h  Ki  <  K2,  then  A  H  Ki  kind  and  A  h  K2  kind. 

3.  If  A  h  C  :  K,  then  A  h  K  kind. 

4.  If  A  h  Cl  =  C2  ;  K,  then  A  h  Ci  ;  K,  A  h  C2  :  K,  and  A  h  K  kind. 

Proposition  3.1.9  (Symmetry  and  Transitivity  of  Kind  Eqnivalence) 

1.  If  A  h  Ki  =  K2,  then  A  h  K2  =  Ki. 

2.  If  A  h  Ki  =  K2  and  A  h  K2  =  K3,  then  A  h  Ki  =  K3. 

Proposition  3.1.10  (Antisymmetry  and  Transitivity  of  Kind  Subtyping) 

1.  A  h  Ki  =  K2  if  and  only  if  A  h  Ki  <  K2  and  A  h  K2  <  Ki. 

2.  If  A  h  Ki  <  K2  and  A  h  K2  <  K3,  then  A  h  Ki  <  K3. 

Proposition  3.1.11  (Functionality) 

Suppose  A'  h  7i  =  72  ;  A. 

1.  If  A  h  K  kind,  then  A'  h  71K  =  72K. 

2.  If  A  h  Ki  =  K2,  then  A'  h  71K1  =  72K2. 

3.  If  A  h  Ki  <  K2,  then  A'  h  71K1  <  72K2. 

4.  If  A  h  C  :  K,  then  A'  h  71C  =  72C  :  71K. 

5.  If  A  h  Cl  =  C2  ;  K,  then  A'  h  71C1  =  72C2  ;  71K. 

3.1.5  Admissible  Rules 

Here  I  enumerate  some  important  admissible  rules,  which  fall  into  three  categories.  First,  Proposi¬ 
tion  3.1.12  states  that  the  inference  rules  involving  singleton  kinds  extend  to  higher-order  singletons 
(as  defined  in  Figure  3.2).  Since  the  well-formedness  of  Sk(C)  does  not  necessarily  imply  that  C 
has  kind  K,  the  latter  must  be  added  as  a  premise  to  the  higher-order  variants  of  some  of  the  rules. 

Second,  Proposition  3.1.13  states  that  (5-  and  ry-equivalence  rules  for  functions  and  products  are 
admissible,  and  also  gives  an  alternative  formulation  of  the  typing,  equivalence  and  extensionality 
rules  for  products.  The  notation  (Ci,C2)  is  shorthand  for  (q;  =  Ci,C2),  where  a  0  FV(C2). 
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Third,  Proposition  3.1.14  gives  several  properties  of  transparent  kinds,  the  most  important  of 
which  is  that  any  two  constructors  of  a  transparent  kind  are  equivalent  at  that  kind.  As  discussed 
in  Section  3.1.2,  this  does  not  imply  that  the  constructors  are  equivalent  at  all  kinds.  I  give  a  proof 
only  for  this  third  proposition,  as  proofs  for  the  first  two  can  be  found  in  Stone’s  thesis  [72]. 

Proposition  3.1.12  (Higher-Order  Singleton  Rules) 

1-  7(Sk(C))  =  S.yK(7C). 

2.  If  A  h  Cl  =  C2  :  K,  then  A  h  Ci  =  C2  :  Sk(C2). 

3.  If  A  h  C  :  K,  then  A  h  Sk(C)  kind  and  A  h  C  :  Sk(C). 

4.  If  A  h  Cl  :  Sk(C2)  and  A  h  C2  :  K,  then  A  h  Ci  =  C2  :  Sk(C2). 

5.  If  A  h  C  :  K,  then  A  h  Sk(C)  <  K. 

6.  If  A  h  Cl  =  C2  ;  Ki  and  A  h  Ki  <  K2,  then  A  h  5ki(Ci)  <  Sk2(C2)- 

Proposition  3.1.13  (Admissibility  of  Beta,  Eta,  and  Alternative  Product  Rules) 

1.  If  A,a;K'  h  C  :  K"  and  A  h  C'  :  K',  then  A  h  (Aa:K'.C)(C')  =  C[C7a]  :  K"[C7a]. 

2.  If  A,  a;K'  h  Ci  =  C2  :  K"  and  A  h  C'^  =  C'2  :  K', 
then  A  h  (Aa;K'.Ci)(C7  =  C2[C^/a]  :  K"[C'Ja\. 

3.  If  A  h  Cl  :  Ki  and  A,  a;Ki  h  C2  :  K2,  then  A  h  7ri(a  =  Ci,  C2)  =  Ci  :  Ki 
and  A  h  7r2(a  =  Ci,C2)  =  C2[Ci/a]  :  K2[Ci/a]. 

4.  If  A  h  Cl  =  C;  ;  Ki  and  A,  a;Ki  h  C2  =  C^  ;  K2,  then  A  h  7ri(a  =  Ci,  C2)  =  C^  :  Ki 
and  A  h  712(0  =  Ci,C2)  =  C^C'i/a]  :  K2[CVa]. 

5.  If  A  h  C  :  noiK'.K",  then  A  h  C  =  Aa;K'.C(a)  :  na;K'.K". 

6.  If  A  h  C  :  SmK'.K",  then  A  h  C  =  (7riC,7r2C)  :  SoiK'.K". 

7.  If  A  h  Sa;K'.K"  kind,  A  h  C'  :  K',  and  A  h  C"  :  K"[C7a],  then  A  h  (C',  C")  :  SoiK'.K". 

8.  If  A  h  Sa;K'.K"  kind,  A  h  C;  =  C'2  :  K',  and  A  h  C'/  =  C'2'  :  K"[C;/a], 
then  A  h  (C'i,C'/)  =  (C^  C'2')  :  Sa:K'.K". 

9.  If  A  h  Sa;K'.K"  kind,  A  h  vriCi  =  7riC2  :  K',  and  A  h  7r2Ci  =  7r2C2  :  K"[7riCi/a], 
then  A  h  Cl  =  C2  ;  SoiK'.K". 

Proposition  3.1.14  (Properties  of  Transparent  Kinds) 

1.  If  A  h  C  :  K,  then  A  h  Sk(C)  =  K. 

2.  If  A  h  Cl  :  K  and  A  h  C2  ;  K,  then  A  h  Ci  =  C2  :  K. 

3.  If  A  h  K'  <  K,  then  K'  is  transparent. 

4.  Sk(C)  is  transparent. 

5.  If  A  h  IK  kind,  then  A  h  Can(]K)  :  K. 
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Proof: 

1.  By  induction  on  the  size  of  K. 

•  Case:  IK  =  1.  Trivial. 

•  Case:  IK  =  5(D).  Since  A  h  C  :  S(D),  we  have  A  h  C  =  D  :  T, 
and  thus  A  h  5(C)  =  5(D). 

•  Case:  IK  =  Sa:Ki.]K2. 

(a)  Since  A  h  vriC  :  IKi,  by  induction  A  h  5Ki(vriC)  =  IKi. 

(b)  Since  A  h  7r2C  :  ]K2[7riC/a],  by  induction  A  h  5K2[7riC/a] (^2C)  =  K2[7riC/a]. 

(c)  By  Proposition  3.1.12,  A,  q;:5ki  (vriC)  ^  =  a  :  5Ki(vriC). 

(d)  By  Functionality,  A,  q;:5ki  (vriC)  ^  IK2[7riC/a]  =  1K2. 

(e)  Thus,  A  l-5iKi(vriC)  x  5iK2[7riCH  (7r2C)  =  Sq;:]Ki.]K2. 

•  Case:  IK  =  na:Ki.IK2. 

(a)  Since  A,a:Ki  h  C(q;)  :  1K2,  by  induction  A,q;:Ki  |-5iK2(C(a))  =  IK2. 

(b)  Thus,  A  h  na:Ki.5K2(C(a))  =  na:Ki.]K2. 

2.  (a)  By  Part  1,  A  h  5ik(Ci)  =  IK  and  A  h  5k(C2)  =  IK,  and  thus  A  h  5ik(Ci)  =  5k(C2). 

(b)  By  Part  3  of  Proposition  3.1.12,  A  h  Ci  :  5ik(Ci),  and  thus  A  h  Ci  :  5k(C2). 

(c)  By  Part  4  of  Proposition  3.1.12,  A  h  Ci  =  C2  :  5ik(C2),  and  thus  A  h  Ci  =  C2  :  IK. 

3-5.  Straightforward. 


3.1.6  Kind  Checking  and  Synthesis 

Figure  3.7  shows  Stone  and  Harper’s  algorithm  for  synthesizing  the  principal  (most-precise)  kind 
for  a  given  type  constructor.  Checking  whether  a  constructor  has  a  certain  kind  is  then  simply  a 
matter  of  checking  whether  the  constructor’s  principal  kind  is  a  subtype  of  it.  The  algorithm  itself 
follows  the  typing  rules  for  constructors  fairly  closely,  except  that  it  only  performs  selfification  in 
the  variable  and  base  type  cases,  and  it  only  uses  subsumption  when  checking  a  function  argument 
against  the  domain  kind  of  the  function.  In  addition,  unlike  the  declarative  rules,  the  algorithm 
requires  as  a  precondition  that  the  context  it  is  given  is  well-formed.  Here  I  state  several  properties 
of  kind  synthesis,  including  that  it  is  sound,  complete  and  deterministic: 

Proposition  3.1.15  (Soundness  and  Other  Properties  of  Kind  Checking/Synthesis) 

Assume  A  h  ok. 

1.  If  A  h  C  ^  K  or  A  h  C  ^  K,  then  A  h  C  :  K. 

2.  Synthesis  is  deterministic,  i.e.,  if  A  h  C  Ki  and  A  h  C  K2,  then  Ki  =  K2. 

3.  If  A  h  C  ^  K,  then  K  is  transparent. 

4.  For  77  ranging  over  any  judgment  defined  in  Figure  3.7, 
if  A  h  77  and  A'  T  A  and  A'  h  ok,  then  A'  h  77. 
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Kind  checking:  A  h  C  K 


AhC^K'  AhK'<K 
A  h  C  ^  K 


Base  type  well-formedness:  A  h  6  ok 


_  AhCi^T  AhC2^T  AhCi^T  AhC2^T 

A  h  unit  ok  A  h  Cl  X  C2  ok  A  h  Ci  ^  C2  ok 

A  h  K  kind  A,  a:K  h  C  ^  T  A  h  K  kind  A,  a:K  h  C  ^  T 
A  h  VaiK.C  ok  Ah  3q;:K.C  ok 

Principal  kind  synthesis:  A  h  C  K 


a:K  €  A 
A  h  a  Sk(ck) 


A  h  6  ok 
A  h  6  ^  Sib) 


AhC'  A,  a:K^  h  ^  A  h  C  ^  Ta:K'.K'  A  h  C  ^  Ta:K'.K' 

A  h  (a  =  C',  C")  ^  Sa:K'.K"  A  h  ttiC  ^  K'  Ah  7r2C  ^  K"[7riC/a] 

A  h  kind  A,  «:K  h  C  ^  A  h  C  ^  liaK' K"  A  h  D  ^ 

A  h  Aa:K'.C  ^  BaiKhK"  A  h  C(D)  ^  K"[D/a] 


Figure  3.7:  Kind  Checking  and  Principal  Kind  Synthesis 


Proposition  3.1.16  (Completeness  of  Kind  Checking) 

If  A  h  C  :  K,  then  A  h  C  Sk(C)  (and  therefore  A  h  C  K  as  well). 

As  the  kind  checking  algorithm  is  syntax-directed,  showing  that  it  terminates  reduces  to  finding 
decision  procedures  for  the  kind  well-formedness  and  sub  typing  judgments.  Both  of  these  are 
syntax-directed  as  well,  but  the  latter  requires  a  method  of  deciding  constructor  equivalence  in  the 
case  of  Rule  15.  The  proof  that  such  a  method  exists  is  quite  difficult  and  constitutes  Stone  and 
Harper’s  chief  contribution.  I  discuss  their  algorithm  and  proof  of  correctness  in  the  next  section. 

3.1.7  Deciding  Constructor  Equivalence 

The  Stone-Harper  algorithm  for  deciding  constructor  equivalence  is  shown  in  Figures  3.8  and  3.9. 
It  comprises  a  number  of  interlocking  judgments,  on  which  I  will  attempt  now  to  impose  some 
narrative  structure. 

First  of  all,  suppose  we  are  given  two  well- formed  constructors  Ci  and  C2  to  be  compared 
at  kind  K  in  context  A.  The  main  judgment  A  h  Ci  C2  :  K  determines  whether  they  are 
equivalent  by  dividing  the  problem  into  a  series  of  subproblems  at  base  kinds.  This  makes  sense 
due  to  extensionality;  Ci  and  C2  are  equivalent  at  pair  kind  precisely  when  their  first  projections 
are  equivalent  and  their  second  projections  are  equivalent,  and  they  are  equivalent  at  arrow  kind 
precisely  when,  for  any  argument  a  of  the  domain  kind,  Ci(a)  is  equivalent  at  €2(0:)  at  the  result 
kind.  At  the  unit  and  singleton  base  kinds,  the  algorithm  trivially  returns  a  positive  answer  because 
all  constructors  are  equivalent  at  one  of  those  kinds.  At  kind  T,  however,  we  must  actually  look 
at  the  constructors! 
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Elimination  Contexts  S  ::=  •  \  £{C)  \  TXiE 
Constructor  Paths  P  :;=  b  \  £{a} 


Natural  kind  extraction:  A  h  P  |  K 


A  h  6  t  T 
A  h  a  I  A(a) 

A  h  P(C)  T  K"[C/a] 

A  h  TTlP  T  K' 

A  h  TTsP  T  K"[7riP/a] 

Weak  head  reduction:  A  h  Ci  C2 

A  h  f  {(Aa;K'.C)C'}  ^  ^{C[C7a]} 

A  h  ^{7ri(a  =  C',C")}  ^  ^{C'} 

A  h  ^{7r2(a  =  C',C")}  ^  ^{C"[C7a]} 

AhP^C  ifAhPT  S(C) 

Weak  head  normalization:  A  h  C  =7  D 

A  h  C  ^  D  if  A  h  C  ^  C'  and  A  h  C'  ^  D 

A  |_  c  C  otherwise 


if  A  h  P  t  na:K'.K" 
if  A  h  P  t  SmK'.K" 
if  A  h  P  t  Sa:K'.K" 


Figure  3.8:  Weak  Head  Normalization  for  Type  Constructors 


When  comparing  two  constructors  at  kind  T,  the  algorithm  first  reduces  the  constructors  to 
weak  head  normal  form  (WHNF)  [62].  Since  the  constructors  have  kind  T,  their  WHNF’s  will  not 
be  A- abstractions,  but  rather  paths,  whose  syntax  is  described  at  the  top  of  Figure  3.8.  A  path  P 
is  either  a  base  type  or  a  sequence  of  eliminations  (ie.,  projections  and  applications)  rooted  at  a 
constructor  variable.  The  notation  i^lC}  used  in  the  definition  of  paths  in  Figure  3.8  signifies  the 
substitution  of  C  into  the  single  hole  •  in  the  elimination  context  £. 

The  first  three  rules  in  the  weak  head  reduction  judgment  A  h  Ci  C2  are  completely 
standard  /3-reduction.  The  fourth  rule  is  non-standard — it  says  that  being  a  path  is  not  equivalent 
to  being  in  WHNF;  to  be  in  WHNF  a  path  must  also  be  abstract.  For  example,  if  a  is  bound 
in  the  context  with  kind  T,  then  a  is  an  abstract  type.  If  a  is  bound  with  S(C),  however,  then 
a  is  transparently  equal  to  C  and  may  thus  be  reduced  to  it.  One  can  think  of  this  reduction 
step  as  “looking  up  the  definition  of  a  type  variable.”  Whether  a  path  has  a  “definition”  or  not 
is  determined  by  a  judgment  called  “natural  kind  extraction”  and  written  A  h  C  |  K.  Intuitively, 
the  natural  kind  of  a  constructor  is  the  kind  you  would  synthesize  for  it  if  the  selfification  rules  did 
not  exist.  This  intuition  is  reflected  in  the  following  fact,  connecting  principal  and  natural  kinds. 

Proposition  3.1.17  (Connection  Between  Natural  and  Principal  Kinds) 

If  A  h  P  ^  K,  then  A  h  P  j  L,  A  h  P  :  L,  and  K  =  5l(P). 

The  natural  kind  of  a  path  will  be  of  the  form  S(C)  if  and  only  if  it  has  a  definition  in  the  context 
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Algorithmic  kind  equivalence:  A  h  Ki  K2 

A  h  1  1 

A  h  T  T 

A  hS(Ci)  4»S(C2)  ifAhCi^C2;T 

A  h  Ua:K[.K'l  ^  if  A  h  K'^  and  A,  aiK^  h  K'{  ^  K" 

A  h  SaiK'i.K'/  TaK'^.K'^  if  A  h  K'2  and  A,  aiK^  h  K'{  ^  K'^ 

Algorithmic  constructor  equivalence:  A  h  Ci  C2  :  K 

A  h  Cl  C2  :  1 

A  h  Cl  ^C2  :S(C) 

AhCi^C2:T  if  A  h  Cl  ^  Pi,  A  h  C2  ^  P2, 

and  A  h  Pi  P2  T  T 

A  h  Cl  ^  C2  :  naiK'.K"  if  A,  a:K'  h  Ci(a)  C2(a)  :  K" 

A  h  Cl  ^  C2  :  SaiK'.K"  if  A  h  ttiCi  7riC2  :  K' 

and  A  h  7r2Ci  7r2C2  :  K"[7riCi/a] 

Algorithmic  path  equivalence:  A  h  Pi  <— >  P2  TK 

A  h  a  <->  a  I  A(q;) 

A  h  unit  unit  j  T 


A 

h 

C'l  X  C’( 

^  C'  X  cn  T 

if 

A 

h 

C'l 

C'2 

:  T  and  A  h  C’(  ^  C'^  :  T 

A 

h 

C[  ^  C'/ 

if 

A 

h 

C'l 

C'2 

:  T  and  A  h  C'(  ^  C'2'  :  T 

A 

h 

VaiKi.C 

1  ^  Va:K2.C2  T  T 

if 

A 

h 

Ki 

K2 

and  A, a:K 

1  hCi 

4^C2  ;  T 

A 

h 

3a:Ki.C 

1  ^  3a:K2.C2  T  T 

if 

A 

h 

Ki 

K2 

and  A,  q;:K 

1  h  Cl 

4»C2  ;  T 

A 

h 

Pi(Ci)^P2(C2)TK"[Ci/a] 

if 

A 

h 

Pi 

P2 

t  na:K'.K" 

and  A 

,  h  Cl  C2 

A 

h 

TTlPl  ^ 

7riP2  T  K' 

if 

A 

h 

Pi 

P2 

t  SaiK'.K" 

A 

h 

7r2Pl  ^ 

7r2P2  T  K"[7riPi/a] 

if 

A 

h 

Pi 

P2 

t  SaiK'.K" 

Figure  3.9:  Equivalence  Algorithm  for  Constructors  and  Kinds 


(namely,  C).  It  is  worth  noting  that  this  is  the  only  place  in  the  whole  equivalence  algorithm  where 
the  context  A  is  actually  consulted. 

Finally,  now  that  we  have  reduced  Ci  and  C2  to  WHNF’s  Pi  and  P2,  we  compare  the  two  paths 
structurally  with  the  judgment  A  h  Pi  ^  P2  t  K-  several  cases,  structural  path  comparison 
requires  recursive  calls  to  the  main  equivalence  judgment  when  it  encounters  subterms,  such  as 
function  arguments,  that  are  not  necessarily  paths.  The  kind  K  in  the  path  equivalence  judgment 
is  the  natural  kind  of  Pi.  It  is  used  in  the  function  application  case  to  synthesize  the  kind  K'  at 
which  the  arguments  Ci  and  C2  are  to  be  compared. 

The  proof  that  this  algorithm  is  sound  is  fairly  straightforward.  The  proof  that  it  is  complete, 
however,  is  quite  complicated,  the  chief  difficulty  being  that  the  algorithm  itself  is  not  obviously 
symmetric  or  transitive!  Specifically,  in  the  pair  kind  case  of  the  main  equivalence  judgment,  the 
second  recursive  call  compares  7r2Ci  and  7r2C2  at  the  kind  K"[7riCi/a].  This  does  not  clearly 
imply  that  the  two  constructors  are  also  algorithmically  equivalent  at  the  kind  K''[7riC2  /a],  which 
is  needed  to  prove  symmetry  and  transitivity.  Similar  asymmetries  in  the  kinds  pop  up  in  the 
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application  and  second  projection  cases  of  path  equivalence. 

This  problem  seems  to  require  one  to  come  up  with  a  variant  of  the  algorithm  that  is  equivalent 
to  it  but  more  obviously  symmetric  and  transitive.  Stone  and  Harper  have  proposed  two  such 
variants.  The  hrst,  described  in  their  POPL  paper  [74],  overcomes  the  asymmetries  of  the  original 
algorithm  by  working  with  two  equivalent  contexts  (Ai  and  A2)  and  two  equivalent  kinds  (Ki  and 
K2)  in  addition  to  the  two  constructors.  The  idea  is  to  divide  the  algorithmic  judgments  into  two 
halves,  such  that  each  C*  only  ends  up  “infecting”  the  kind  Kj  and  context  Aj  on  its  own  half  of 
the  judgment.  The  proof  that  this  algorithm  is  complete  involves  a  Kripke-style  logical  relations 
argument  that  is  fairly  straightforward  aside  from  the  fact  that,  like  the  algorithm,  it  also  deals 
with  two  contexts  and  two  kinds. 

The  clunky  nature  of  the  six-place  algorithm  leads  its  proof  of  completeness  to  be  rather  ver¬ 
bose.  More  recently.  Stone  discovered  an  alternative  algorithm/proof  that  is,  I  believe,  much  easier 
to  follow.  While  structured  like  the  original  algorithm,  it  takes  the  form  of  a  normalization  pro¬ 
cedure  for  constructors  that  is  both  context-  and  kind-dependent.  Two  constructors  are  deemed 
equivalent  if  they  have  the  same  normal  form,  so  symmetry  and  transitivity  fall  out  trivially.  More 
interesting  is  the  logical  relation  used,  which  has  the  form  C  \n  JC  [D],  where  D,  C  and  1C  are  sets 
of  contexts,  constructors  and  kinds,  respectively.  The  logical  relation  has  the  property  that  all  of 
the  constructors  in  C,  when  compared  at  any  of  the  kinds  in  1C  and  under  any  of  the  contexts  in  V, 
have  the  same  normal  form.  The  strengthened  induction  hypothesis  implied  by  this  logical  relation 
results  in  a  completeness  proof  that  is  considerably  more  elegant  and  readable  than  the  original. 

It  is  described  in  detail  in  Stone  and  Harper’s  forthcoming  journal  version  of  their  paper  [75]. 

Given  soundness  and  completeness,  it  is  not  hard  to  show  that  the  equivalence  algorithm  is  decid¬ 
able.  One  consequence  of  decidability  is  that  all  well-formed  constructors  have  (unique)  WHNF’s. 
This  is  useful  particularly  when  proving  decidability  of  type  synthesis  (see  Section  3.2.4  below). 

Theorem  3.1.18  (Soundness,  Completeness  and  Decidability  of  Equivalence  Algorithm) 

1.  If  A  h  Ki  kind  and  A  h  K2  kind,  then  A  h  Ki  =  K2  if  and  only  if  A  h  Ki  K2, 
which  is  decidable. 

2.  If  A  h  Cl  :  K  and  A  h  C2  :  K,  then  A  h  Ci  =  C2  :  K  if  and  only  if  A  h  Ci  C2  :  K, 
which  is  decidable. 

3.  If  A  h  Pi  :  Ki  and  A  h  P2  :  K2  and  A  h  Pi  ^  P2  T  K,  then  A  h  Pi  =  P2  :  K. 

Proposition  3.1.19  (Well-Formed  Constructors  Have  Weak  Head  Normal  Forms) 

If  A  h  C  :  K,  then  there  exists  a  unique  D  such  that  A  h  C  D,  and  moreover  A  h  C  =  D  :  K. 

3.2  Terms 

In  this  section,  I  present  the  term  layer  of  my  core  language.  Unlike  the  constructor  and  kind 
languages,  this  term  language  is  a  completely  standard  explicitly- typed  variant  of  the  term  language 
ofF^. 

3.2.1  Syntax 

Figure  3.10  gives  the  syntax  of  terms  and  values.  I  have  organized  the  language  so  that  all  intro¬ 
duction  forms  are  values  and  all  values  are  introduction  forms,  except  for  value  variables  x.  A  term 
e  is  either  a  value  v,  an  elimination  form,  or  a  let-expression.  There  are  two  kinds  of  let-expressions. 
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Value  Variables 

x,y 

G  Val  Vars 

Values 

V,  w 

::=  X  1  0  1  {vi,V2)  1  fun  x(xi:Ci) 

l:C2.e  1 

Aa:K.e  pack  [C,u]  as  D 

Terms 

e,f 

;:=  V  TTiV  vi{v2)  u[C]  let  [a, 

x]  =  unpack  x  in  (e  :  C) 

let  a  =  C  in  e  let  X  =  ei  in 

62 

Dynamic  Contexts 

T 

:;=  0  1  F,a:K  |  r,x;C 

Figure  3.10;  Syntax  of  Terms  and  Values 


(61,62) 

def 

let  xi  =  Cl  in  let  X2  =  62  in  (xi,X2) 

TTiC 

def 

let  X  =  e  in  tTjX 

61(62) 

def 

let  xi  =  Cl  in  let  X2  =  62  in  xi(x2) 

6[C] 

def 

let  X  =  e  in  x[C] 

pack  [C,  e]  as  D 

def 

let  X  =  e  in  pack  [C,x]  as  D 

let  [a,  y]  =  unpack  e  in  (e' :  C) 

def 

let  X  =  e  in  let  [a.,y]  =  unpack  x  in 

Figure  3.11:  Less  Restrictive  Versions  of  Term  Constructs 


The  first,  let  a  =  C  in  e,  binds  C  to  a  inside  e.  This  construct  is  in  fact  encodable  as  (AQ;:K.e)[C], 
where  K  is  the  principal  kind  of  C.  As  this  is  not  a  direct  syntactic  encoding,  however,  I  have 
included  the  construct  as  primitive  for  convenience.  The  second  let  construct,  let  x  =  ei  in  62, 
evaluates  ei  to  a  value  v,  which  is  then  bound  to  x  inside  €2-  Using  this  construct,  we  can  easily 
define  less  restrictive  versions  of  several  of  the  term  constructs  (shown  in  Figure  3.11)  in  which  the 
subterms  are  permitted  to  be  arbitrary  terms  and  are  evaluated  in  left-to-right  order. 

Note  that  the  elimination  form  for  existentials,  let  [a,x]  =  unpack  v  in  (e:C),  includes  a  type 
annotation  C  on  the  result  which  must  be  well-formed  in  the  ambient  context  of  the  term,  i.e.,  C 
may  not  refer  to  the  local  type  variable  a.  To  eliminate  clutter,  I  will  sometimes  omit  the  type 
annotation  C  when  it  is  clear  from  context  what  it  should  be. 

Finally,  Figure  3.10  also  defines  the  syntax  of  dynamic  contexts,  which  extend  static  contexts 
with  bindings  of  value  variables  to  their  types.  There  is  a  straightforward  erasure  of  dynamic 
contexts  into  static  contexts,  defined  by  the  following  Fst(-)  function: 

Fst(0)  =  0 
Fst(F,a:K)  =  Fst(r),a:K 
Fst(F,x:C)  =  Fst(r) 


3.2.2  Static  Semantics 

Figure  3.12  shows  the  inference  rules  for  the  judgments  of  well- formed  terms  and  dynamic  contexts, 
all  of  which  are  straightforward.  The  only  point  of  note  is  that  the  premises  of  some  rules  refer 
to  constructor  and  kind  judgments  using  dynamic  contexts  F  in  place  of  static  contexts  A.  The 
meaning  of  these  premises  is  explained  by  the  following  definition: 
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Well- formed  dynamic  contexts:  F  h  ok 


h  ok 


(52) 


r  h  K  kind 
r,  a:K  h  ok 


(53) 


r  h  C  :  T 

r,  x:C  h  ok 


(54) 


Well-formed  terms:  F  h  e  :  C 


F  h  ok  x:C  e  F 
F  h  X  :  C 

F  h  x'  :  C'  F  h  x"  :  C" 


(55) 


F  h  ok 


TT  (56) 


Fh  (x',x")  :  C'xC" 

F,x:C'^C",x';C'  h  e  :  C" 
Fhfun  x(x':C'):C".e  :  C' ^  C' 

F,a:K  h  e  :  C  ,  . 

(61) 


(57) 

X  (59) 


F  h  0  :  unit 
FhxiCixCs  iG{l,2} 


(58) 


F  h  TTiV  :  Ci 
F  h  X  :  C'  ^  C  F  h  x'  :  C' 


F  h  x(x')  :  C 
F  h  X  :  Va;K.C  F  h  D  :  K 


(60) 


F  h  AaiK.e  :  VaiK.C  F  h  x[D]  :  C[D/a] 

F  h  D  =  3a;K.C' :  T  FhC:K  Fhx:C'[C/a] 
F  h  pack  [C, x]  as  D  :  D 

F  h  X  :  3a:K.C'  F,  a:K,  x:C'  h  e  :  C  F  h  C  :  T 


(62) 


(63) 


F  h  let  [a,  x]  =  unpack  x  in  (e :  C)  :  C 
Fhe';C'  F,x:C'he:C 


(64) 


F  h  let  X  =  e'  in  e  :  C 


(66) 


FhC:K  F,a;Khe:D 
F  h  let  a  =  C  in  e  :  D[C/q;] 

Fhe:C'  FhC'  =  C:T 


(65) 


F  h  e  :  C 


(67) 


Figure  3.12:  Inference  Rules  for  Terms  and  Dynamic  Contexts 


Definition  3.2.1  (Static  Judgments  with  Dynamic  Contexts) 

For  any  judgment  form  J  (except  “ok”)  defined  in  Figures  3.4  and  3.5, 
let  F  h  77  be  shorthand  for  the  conjunction  of  F  h  ok  and  Fst(F)  h  J . 

3.2.3  Declarative  Properties 

It  is  easy  to  check  that  all  the  propositions  stated  in  Sections  3.1.3  and  3.1.4  involving  static  contexts 
may  be  restated  using  dynamic  contexts  instead  {i.e.,  by  syntactically  replacing  all  instances  of  a  A 
with  a  corresponding  instance  of  a  F),  and  that  all  the  structural  properties  (except  Substitution) 
concerning  an  arbitrary  judgment  J  apply  to  the  term  typing  judgment  as  well.  Additionally,  we 
have  the  following  new  properties: 

Proposition  3.2.2  (Subderivations) 

Every  proof  of  Fi,x:C,F2  F  J  contains  a  strict  subderivation  of  Fi  h  C  :  T. 

Proposition  3.2.3  (Weakening) 

If  Fi,  x:C2,  Fs  F  J  and  Fi  F  Ci  =  C2  :  T,  then  Fi,  x:Ci,  F2  F  J. 


Proposition  3.2.4  (Validity) 

If  F  F  e  :  C,  then  F  F  C  :  T. 
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Type  checking:  F  h  e  C 

Fhe^C^  rhC'  =  C:T 
Fhe^C 

Normalized  type  synthesis:  Fhe^C 


Fhe^C^  FhC'^C 
Fhe^C 


Type  synthesis:  F  h  e  C 

x:C  €  F  _  F  h  t?!  ^  Cl  F  h  z;2  ^  C2  F  h  u  Ci  x  C2 

Fhx=^C  Fh()=>  unit  F  h  (vi,  V2}  Ci  x  C2  F  h  TTjV  Cj 

FhC'^C":T  F,x:C'^C",x':C'he^C"  Fhx'^C' 

F  h  fun  x(x':C0:C".  e^C'^C"  F  h  v{v')  ^  C 

F  h  K  kind  F,  a;K  h  e  ^  C  F  h  x  ^  VaiK.C  F  h  D  :  K 
F  h  Aa:K.e  ^  VaiK.C  F  h  x[D]  ^  C[D/a] 

FhD:T  FhD^3a:K.C'  FhC:K  Fhx^C'[C/a] 

F  h  pack  [C, x]  as  D  D 

Fhx^3a:K.C^  F,  a:K,  x:C^  h  e  ^  C  FhC:T 
F  h  let  [a,  x]  =  unpack  x  in  (e :  C)  ^  C 

FhC^K  F,«:Khe^D  F  h  e' ^  F,x:C^he^C 
F  h  let  a  =  C  in  e  D[C/a]  F  h  let  x  =  e'  in  e  C 

Figure  3.13:  Type  Checking  and  Type  Synthesis 


3.2.4  Type  Checking  and  Synthesis 

Figure  3.13  gives  an  algorithm  for  synthesizing  the  type  of  a  term,  which  is  unique  modulo  type 
equivalence.  It  is  completely  straightforward.  The  only  point  of  note  is  that  in  several  places  I 
make  use  of  weak  head  normalization  in  order  to  reduce  a  given  or  synthesized  type  C  into  the 
form  of  a  base  type  b.  Here  I  state  several  properties  of  type  synthesis,  including  that  it  is  sound, 
complete  and  deterministic.  Decidability  is  easy  to  show,  as  the  algorithm  is  syntax-directed. 

Proposition  3.2.5  (Soundness  and  Other  Properties  of  Type  Checking/Synthesis) 

Assume  F  h  ok. 

1.  IfFhe^CorFhe^CorFhe^C,  then  F  h  e  :  C. 

2.  Type  synthesis  is  deterministic,  i.e.,  if  F  h  e  ^  Ci  and  F  h  e  ^  C2,  then  Ci  =  C2. 

3.  For  77  ranging  over  any  judgment  defined  in  Figure  3.13, 
if  F  h  J  and  F'  D  F  and  F'  h  ok,  then  F'  h  J. 
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V  =  fun  x{x':C'):C" .  e 

'^i{vi,V2)  Vi  v{v')  I— >  e\v/x\[v' /x']  (Aa:K.e)[C]  i— e[C/a] 


let  [a,x\  =  unpack  (pack  [C,  t;]  as  D)  in  (e :  C')  e[C/a\[v/x\ 

Cl  1-^  e\ 

let  a  =  C  in  e  e[C/a]  let  x  =  ei  in  62  let  x  =  e'^  in  62  let  x  =  x  in  e  1— >  e[x/x] 
Figure  3.14:  Dynamic  Semantics  of  the  Core  Language 

Proposition  3.2.6  (Completeness  of  Type  Checking) 

If  r  h  e  :  C,  then  F  h  e  ^  C. 

3.2.5  Dynamic  Semantics  and  Type  Safety 

Figure  3.14  gives  the  dynamic  semantics  for  the  core  language,  in  the  form  of  a  small-step  opera¬ 
tional  semantics.  Again,  it  is  completely  standard. 

The  proof  of  type  safety  is  done  in  the  usual  manner,  via  preservation  and  progress  theorems, 
which  rely  respectively  on  the  substitution  and  canonical  forms  lemmas  stated  below.  The  proofs 
of  the  following  properties,  except  for  Substitution,  use  the  type  synthesis  algorithm  of  the  previous 
section  in  order  to  regularize  the  structure  of  term  typing  derivations. 

Lemma  3.2.7  (Substitution  for  Term  Typing  Jndgment) 

1.  If  Fi,a:K,F2  h  e  :  D  and  Fi  h  C  :  K,  then  ri,F2[C/a]  h  e[C/a]  :  D[C/a]. 

2.  If  Fi,  x:C,  r2  h  e  :  D  and  Fi,  r2  b  x  :  C,  then  Fi,  F2  b  e[x/x]  :  D. 

Lemma  3.2.8  (Canonical  Forms) 

Suppose  0  b  X  :  C.  Then: 

1.  If  C  is  of  the  form  unit,  then  x  is  of  the  form  (). 

2.  If  C  is  of  the  form  Ci  x  C2,  then  x  is  of  the  form  (xi,X2). 

3.  If  C  is  of  the  form  Ci  — >  C2,  then  x  is  of  the  form  fun  x(xbC^):C'b  e. 

4.  If  C  is  of  the  form  Vq;:K.C,  then  x  is  of  the  form  AQ;:Kbe. 

5.  If  C  is  of  the  form  3q;:K.C,  then  x  is  of  the  form  pack  [C^,x^]  as  D. 

Theorem  3.2.9  (Progress) 

If  0  b  e  :  C,  then  either  e  is  a  value  or  there  exists  a  unique  U  such  that  e  ^  e' . 

Theorem  3.2.10  (Preservation) 

If  0  b  e  :  C  and  e  1-^  e',  then  0  b  e'  :  C. 


Chapter  4 

A  Type  System  for  ML  Modules: 
Module  Language 


In  this  chapter,  I  will  present  the  module  language  of  my  type  system  for  ML  modules,  built  on 
top  of  the  core  language  of  Chapter  3.  The  high-level  design  of  this  module  language  has  already 
been  motivated  and  outlined  in  Chapter  2.  The  goal  of  the  present  chapter  is  to  explain  the  formal 
details  and  meta-theoretic  properties  of  the  language. 

In  Section  4.1,  I  will  present  the  language  of  signatures,  which  serve  as  the  types  of  modules. 
Thanks  to  the  inclusion  of  singleton  kinds  in  the  type  structure  of  the  core  language,  the  concept 
of  translucent  signatures  is  very  easy  to  account  for.  I  will  state  and  prove  a  number  of  properties 
of  signatures,  and  I  will  also  show  how  to  interpret  signatures  in  terms  of  core-language  kinds  and 
types,  via  a  translation  known  as  “phase-splitting.”  In  Section  4.2,  I  will  present  the  language  of 
modules  itself.  While  modules  do  extend  the  term  structure  of  the  core  language  in  order  to  allow 
the  projection  of  value  components  from  modules,  they  do  not  extend  the  type  structure  of  the  core 
language  and  thus  do  not  complicate  the  problem  of  deciding  type  equivalence.  I  will  give  a  sound 
and  complete  signature  checking  algorithm  for  the  module  language,  and  I  will  also  show  how  to 
phase-split  modules  into  core-language  type  constructors  and  terms,  which  may  then  be  evaluated 
according  to  the  core-language  dynamic  semantics  given  in  Section  3.2.5. 


4.1  Signatures 

4.1.1  Syntax 

The  syntax  of  signatures  is  given  in  Figure  4.1.  Figure  4.2  illustrates  how  the  constructs  in  the 
signature  language  correspond  roughly  to  the  signatures  one  finds  in  ML  code.  ^  Let  us  look  at  the 
signature  forms  shown  in  Figure  4.1  one  at  a  time. 

The  unit  signature  1  corresponds  to  an  empty  signature  with  no  specifications.  The  kind 
signature  |K]  corresponds  to  a  signature  with  a  single  specification  of  a  type  constructor  with  kind 
K.  The  type  signature  |C]  models  a  signature  with  a  single  specification  of  a  value  component 
whose  type  is  C. 

The  pair  signature  SX;Si.S2  describes  a  module  consisting  of  a  pair  of  submodules.  The  sig¬ 
nature  S2  of  the  second  submodule  may  refer  to  type  components  of  the  first  submodule,  whose 

^This  is  only  a  loose  correspondence,  meant  to  provide  some  intuition.  A  more  precise  correspondence  will  be 
given  in  the  definition  of  my  new  ML  dialect  in  Part  III. 
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Module  Variables 

X,Y  G 

ModVars 

Totality  Classifiers 

r  ::= 

tot 

par 

Signatures 

S,R  ::= 

1  1 

IKII 

ici 

SX;Si.S2 

n”X:Si.S2 

Transparent  Signatures 

S,M  ::= 

1 

1 

ici 

SX:Si  .§2 

nt°tX:Si.S2  1  nP"^X:Si.S2 

Figure  4.1;  Syntax  of  Signatures 


1  ; 

«  sig  end 

ITI 

-  sig  type 

t  end 

|T”  ^  T|  ; 

-  sig  type 

(>ai,...C 

ls(c)l 

-  sig  type 

t  =  C  end 

ICI 

sig  val  X  :  C  end 

XX:Si.S2  f 

-  sig 

structure  X  :  Si 
structure  Y  :  S2 

end 


n’'X:Si.S2  ~  functor  (X  :  Si)  ->  S2 
Figure  4.2:  Correspondence  With  ML  Signatures 


signature  is  Si,  through  the  module  variable  X.  The  analogy  between  SX:Si.S2  and  the  corre¬ 
sponding  ML  signature  shown  in  Figure  4.2  is  not  quite  precise:  in  ML  submodules  are  accessed 
by  name,  whereas  in  this  calculus  submodules  are  accessed  by  position.  Hence,  while  the  variable 
name  X  is  alpha-convertible  in  SX;Si.S2,  changing  X  to  X'  in  the  corresponding  ML  signature 
results  in  an  inequivalent  signature. 

Lastly,  the  functor  signature  n'^X:Si.S2  describes  a  functor  with  argument  signature  Si  and 
result  signature  S2,  where  S2  may  refer  to  type  components  of  the  argument  module  through 
the  variable  X.  The  r  is  a  “totality  classifier,”  which  is  either  tot  or  par  depending  on  whether 
the  functor  is  total  or  partial,  respectively.  I  will  sometimes  write  nX:Si.S2  as  shorthand  for 
n'^°'^X:Si.S2.  When  X  ^  FV(S2),  I  will  also  sometimes  use  Si  x  S2  and  Si  — ^  S2  as  shorthand  for 
SX:Si.S2  and  n”X:Si.S2,  respectively. 

Of  course,  real  ML  signatures  do  not  have  as  restricted  a  form  as  the  signatures  in  this  calculus — 
they  may  specify  an  arbitrary  sequence  of  types,  values  and  submodules.  The  signature  forms  in  this 
type  system  are  intended  to  represent  a  convenient  and  concise  abstraction  of  the  expressive  power 
of  ML  signatures,  and  what  they  lack  in  programming  flexibility  they  make  up  for  in  simplicity. 

There  are  several  points  to  observe  about  this  signature  language.  First,  in  practice,  the  K  in 
the  kind  signature  [K]  will  only  range  over  a  restricted  class  of  kinds:  type  constructors  at  the  ML 
source  level  are  either  monomorphic  (like  unit),  in  which  case  they  have  kind  T,  or  polymorphic, 
(like  list),  in  which  case  they  are  functions  that  take  some  number  of  arguments  n  of  kind  T  and 
return  a  type  of  kind  T.  ML’s  “opaque”  type  specifications  thus  correspond  to  kind  signatures  of 
the  form  [T]  or  IT”— >T],  which  do  not  reveal  any  information  about  the  type  constructors  that 
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Fst(l) 

Fst(lKl) 

Fst([Cl) 

Fst(SX:Si.S2) 

Fst(nt°tX:Si.S2) 

Fst(nP"^X:Si.S2) 


def  ^ 

=  K 

def  ^ 

=  SX":Fst(Si).Fst(S2) 
=  nX";Fst(Si).Fst(S2) 

def 


Figure  4.3:  Extracting  the  Static  Part  of  a  Signature 


inhabit  them  (besides  their  arity  n).^  Mb’s  “transparent”  type  specifications,  in  turn,  correspond 
to  kind  signatures  [K]  where  K  is  a  transparent — in  particular  a  singleton — kind. 

Second,  while  the  pair  and  functor  signature  constructs  contain  binding  sites  for  module  vari¬ 
ables,  I  have  failed  to  provide  a  way  for  signatures,  constructors  or  kinds  to  ever  refer  to  those 
module  variables!  To  remedy  this  situation,  I  assume  an  injection  (•)'^  from  ModVars  into  ConVars, 
that  is,  for  every  module  variable  X,  there  is  a  corresponding  constructor  variable  X'^,  with  the  prop¬ 
erty  that  X  =  Y  if  and  only  if  X'^  =  In  addition,  wherever  X  is  bound,  X'^  is  implicitly  bound 
as  well.  The  idea  is  that,  if  X  stands  for  a  module  M,  then  X'^  is  a  constructor  variable  representing 
the  type  components  of  M.  Then,  instead  of  projecting  types  from  X  directly,  which  would  require 
extending  the  type  language,  we  project  them  from  the  constructor  X'^. 

The  introduction  of  X*^  begs  the  question:  if  a  module  variable  X  has  signature  S,  what  is  the 
kind  of  X'^?  The  answer  is  given  by  the  meta-level  function  Fst(S),  defined  in  Figure  4.3.  Intuitively, 
if  X  has  S,  then  Fst(S)  describes  the  ways  in  which  type  components  may  be  extracted  from  X 
(or  rather,  from  X*^).  If  S  =  [K],  then  X'^  is  the  one  and  only  constructor  component  of  X,  so  it 
has  kind  K.  If  S  =  |C],  then  X  has  a  single  value  component  and  no  type  components,  so  X'^  is 
equivalent  to  ()  and  has  kind  1.  For  unit  and  pair  signatures,  Fst(S)  is  defined  in  the  obvious  way. 

The  definition  of  Fst(S)  gets  slightly  tricky  when  S  is  a  functor  signature.  When  S  =  n'^°'^Y:Si.S2, 
type  components  may  be  extracted  from  X  by  first  applying  it  to  a  module  with  signature  Si  and 
then  projecting  types  from  the  result.  Since  X  is  a  separably  total  functor,  however,  we  know 
that  the  type  components  in  X’s  result  can  only  depend  on  the  type  components  in  its  argument. 
Correspondingly,  X*^  is  a  constructor  function  from  the  static  part  of  its  argument  to  the  static  part 
of  its  result  and  has  kind  nY'^:Fst(Si).Fst(S2).  On  the  other  hand,  when  S  =  nP^''Y:Si.S2,  there  is 
no  way  to  extract  type  components  from  X  because  any  application  of  X  will  be  deemed  impure 
and  therefore  non-projectible.  Consequently,  X'^  is  useless — to  indicate  this,  I  equate  it  with  the 
unit  constructor  ()  and  define  Fst(nP^'’Y:Si.S2)  to  be  1.  In  the  proofs  of  several  properties  of  the 
module  language,  it  is  convenient  to  group  together  signatures  S  for  which  Fst(S)  is  the  unit  kind, 
namely  signatures  of  the  form  1,  |C]  or  nP^'’Y:Si.S2.  I  will  refer  to  these  signature  forms  as  unitary. 

Finally,  analogous  to  the  notion  of  higher-order  singleton  kinds.  Figure  4.4  defines  a  notion  of 
singleton  signatures.^  Intuitively,  the  singleton  signature  5s (C)  describes  precisely  those  modules 
of  signature  S  whose  static  parts  (of  kind  Fst(S))  are  equivalent  to  C.  Given  this  intuition,  the 
formal  definition  itself  is  fairly  straightforward.  Singleton  signatures  will  come  in  very  handy  in 

here  stands  for  T  x  •  •  •  x  T. 

n  times 

^Similarly  to  higher-order  singleton  kinds,  Ss(C)  is  defined  inductively  on  the  size  of  the  signature  S,  using  the 
size  metric  of  Definition  4.1.2. 
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Si(C) 

5[ki(C) 

S|D](C) 

SsX:Si.S2(C) 

Sn‘°*X:Si.S2(C) 

•5np="'X:Si.S2(C) 


def 

def 

def 

def 

def 

def 


1 

[Sk(C)] 

PI 

Ssi(vriC)  X  Ss2[7riC/Xp](7r2C) 

nt°tX:Si.Ss2(C(X^)) 

nP"^X:Si.S2 


Figure  4.4:  Singleton  Signatures 


formalizing  the  idea  of  selfification  at  the  level  of  modules  in  much  the  same  way  that  higher-order 
singleton  kinds  formalize  selfification  at  the  level  of  type  constructors. 

Singleton  signatures  are  a  special  case  of  a  more  general  subclass  of  transparent  signatures, 
written  S,  whose  syntax  is  defined  in  Figure  4.1.  Conceptually,  a  transparent  signature  is  a  signature 
in  which  the  type  components  (if  there  are  any)  are  fully  specihed,  i.e.,  have  transparent  kinds.  More 
formally,  S  is  a  transparent  signature  if  and  only  if  Fst(S)  is  a  transparent  kind.  One  consequence 
of  this  definition  is  that  all  unitary  signatures  are  considered  transparent — in  particular,  a  partial 
functor  signature  is  considered  transparent,  even  if  its  result  signature  is  not.  This  makes  sense; 
since  no  type  components  may  be  extracted  from  a  partial  functor,  it  is  indeed  the  case  that 
all  zero  of  them  are  transparently  specified.  The  ability  to  syntactically  distinguish  transparent 
signatures  is  useful  both  in  the  typing  judgment  for  modules  (presented  in  Section  4.2.3)  and  in 
the  meta-theory  of  the  module  language. 

4.1.2  Static  Semantics 

Figure  4.5  shows  the  inference  rules  for  the  judgments  of  well-formed  signatures,  signature  equiva¬ 
lence  and  signature  subtyping.  The  important  thing  to  note  about  all  three  judgments  is  that  they 
employ  a  static  context  A,  not  a  dynamic  context  F.  Thus,  in  the  cases  of  S  and  IT  signatures, 
instead  of  binding  the  module  variable  X  in  the  context^  with  signature  Si,  we  bind  X*^  in  the 
context  with  Fst(Si).  As  explained  in  the  previous  section,  this  is  feasible  because  S2  only  needs 
to  refer  to  the  type  components  of  X,  which  are  represented  by  X*^.  I  have  defined  the  judgments 
in  this  way  so  as  to  emphasize  the  point  that  signatures  are  purely  static  entities,  which  may  only 
depend  on  other  static  entities  such  as  constructors  and  kinds,  not  on  dynamic  values. 

The  well-formedness  and  equivalence  judgments  are  completely  straightforward.  The  subtyping 
judgment,  however,  requires  a  bit  of  explanation.  The  point  of  signature  subtyping  in  this  calculus 
is  to  allow  the  identities  of  a  module’s  type  components  to  be  forgotten  when  coercing  the  module 
from  a  more  transparent  signature  to  a  more  opaque  signature.  This  is  not  as  liberal  as  signature 
matching  in  ML,  which  additionally  permits  both  the  dropping  and  reordering  of  components  and 
the  specialization  of  polymorphic  value  components.  These  other  features  of  ML’s  signature  match¬ 
ing  are  important,  but  they  can  be  supported  by  generating  explicit  coercions  between  signatures 
(see  Chapter  9  for  details). 

The  subtyping  defined  in  Figure  4.5  allows  for  the  forgetting  of  a  module’s  type  components  via 
Rule  79,  which  uses  kind  subtyping  to  implement  the  forgetfulness.  Subtyping  is  defined  at  pair 

^The  ability  to  bind  module  variables  in  the  context  will  be  introduced  in  Section  4.2.1. 
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Well-formed  signatures:  A  h  S  sig 


A  h  ok 
A  h  1  sig 


(68) 


A  h  K  kind 


A  h  |K]  sig 


(69) 


A  h  C  :  T 
A  h  |C1  sig 


(70) 


Ah  S'  sig  A,XhFst(S')  h  S"  sig 
A  h  SXiS'.S"  sig 


(71) 


Ah  S'  sig  A,XhFst(S')  h  S"  sig 
A  h  n^X:S'.S"  sig 


(72) 


Signature  equivalence:  A  h  Si  =  S2 


^^(73) 


A  h  Ki  =  K2 


(74) 


A  h  Cl  =  C2  :  T 


(75) 


A  h  S'l  =  S'2  A,  XhFst(S;)  h  S'/  =  S'2' 


A  h  iKil  =  [K2I  ^  '  Ah  |Cil  =  IC2I 

AhS'2  =  S/  A,XhFst(S/)  h  S/ =  S/ 


A  h  SX:S/.S/  =  SX:S/.S 


(76) 


A  h  n^X:S/.S/  =  n^X:S'2.S( 


(77) 


Signature  subtyping:  A  h  Si  <  S2 


A  h  ok 


(78) 


A  h  Ki  <  K2 


(79) 


A  h  Cl  =  C2  :  T 


Ahl<l^’^'  Ah|Kil<|K2r  Ah|Cil<IC2l 

A  h  S/  <  S'2  A,  XhFst(S/)  h  S/  <  S'2'  A  h  SXiS/.S'/  sig 


(80) 


A  h  SX:S/.S/  <  SX:S'2.S^ 


(81) 


A  h  S/  =  S/  A,  XhFst(S'2)  h  S/  <  S'^ 


A  h  nt°tX:S/.S/  <  nt°tX:S'2.S 


(82) 


A  h  S'2  =  S/  A, XhFst(S/)  h  S/  =  S/ 


A  h  nP"'X:S/.S/  <  nP"'X:S'2.S 


(83) 


Figure  4.5:  Inference  Rules  for  Signatures 


signatures  in  the  standard  covariant  manner.  For  functor  signatures,  though,  subtyping  is  very 
restrictive:  total  functor  signatures  are  not  considered  subtypes  of  partial  functor  signatures,  and 
subtyping  for  both  kinds  of  signatures  is  invariant,  not  contravariant,  in  the  argument.  In  fact, 
for  partial  signatures,  subtyping  is  even  invariant  in  the  result.  I  will  explain  the  specific  technical 
reasons  for  these  restrictions  in  Section  4.1.4,  but  essentially  they  are  due  to  the  lack  of  subtyping — 
at  the  level  of  types,  not  kinds — in  the  core  language.  Nevertheless,  as  with  the  other  features  of 
Mb’s  signature  matching,  it  is  possible  to  define  a  more  standard  co-  and  contra- variant  formulation 
of  functor  subtyping  by  means  of  explicit  module  coercions,  and  I  will  do  so  in  Chapter  9. 


4.1.3  Declarative  Properties 

Unlike  the  core  language  of  Chapter  3,  the  module  language  of  this  chapter  is  presented  here  in  a 
new  formulation  for  which  the  meta-theory  has  not  previously  been  written  down.  I  will  therefore 
give  proofs  of  any  theorems  that  are  not  entirely  straightforward.  Fortunately,  there  are  not  many. 

First,  it  is  easy  to  check  that  the  basic  structural  properties  stated  in  Section  3.1.3  (Proposi¬ 
tions  3.1.1,  3.1.2,  3.1.4,  and  3.1.5)  all  hold  for  the  new  signature  judgments  defined  above.  The 
Substitution  property  relies  on  the  fact  that  substitution  commutes  with  Fst(S)  and  5s(C),  as 
stated  by  the  following  proposition: 
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Proposition  4.1.1  (Substitution  Commutes  With  Fst(S)  and  5s(C)) 

1.  7(Fst(S))  =  Fst(7S). 

2.  7(Ss(C))=S^s(7C). 

With  the  structural  properties  in  hand,  we  now  state  some  basic  facts  about  Fst(S)  and  5s(C), 
namely:  that  they  commute  with  each  other,  that  they  take  well-formed  arguments  to  well-formed 
results,  and  that  Fst  preserves  the  equivalence/subtyping  relationships  of  its  arguments.®  It  is 
useful  to  prove  these  facts  before  anything  else,  since  Fst(-)  at  least  is  ubiquitous  in  the  signature 
judgments.  Luckily,  this  is  completely  straightforward.  The  proofs  of  these  and  other  properties  of 
signatures  are  by  induction  on  the  size  of  signatures,  as  defined  by  the  following  metric; 

Definition  4.1.2  (Sizes  of  Signatures) 

Let  the  size  of  a  signature  S,  written  size(S),  be  defined  inductively  as  follows: 


size(l) 

size(|K]) 

size(|C]) 

size(SX;Si.S2) 

size(n^X:Si.S2) 


=  1 -F  size(Si) -F  size(S2) 
'=  1 -F  size(Si) -F  size(S2) 


Note  that  size(Ss(C))  =  size(S)  for  all  S  and  C. 


Proposition  4.1.3  (Facts  About  Fst(S)  and  Ss(C)) 

1.  If  A  h  C  :  Fst(S),  then  A  h  Fst(Ss(C))  =SFst(s)(C). 

2.  If  A  h  S  sig,  then  A  h  Fst(S)  kind. 

3.  If  A  h  S  sig  and  A  h  C  :  Fst(S),  then  A  h  5s (C)  sig. 

4.  If  A  h  Si  =  S2,  then  A  h  Fst(Si)  =  Fst(S2). 

5.  If  A  h  Si  <  S2,  then  A  b  Fst(Si)  <  Fst(S2). 

Proof:  By  induction  on  the  size  of  the  given  signature(s).  ■ 


The  following  properties  of  signatures,  which  are  all  analogous  to  properties  of  kinds,  also  admit 
completely  straightforward  proofs  by  induction  on  the  sizes  of  the  given  signatures.  Those  familiar 
with  the  Stone-Harper  meta-theory  may  be  surprised  that  the  proofs  of  validity  and  functionality 
for  signatures  are  completely  straightforward,  since  at  the  kind  level  they  are  not.  At  the  kind  level, 
validity  and  functionality  are  intertwined:  kind-level  validity  depends  on  constructor-level  validity, 
which  in  turn  depends  on  kind-level  functionality,  and  the  proof  of  functionality  itself  depends  on 
validity.  This  cycle  can  be  broken,  but  it  requires  some  work  (the  Stone-Harper  technical  report  [73] 
and  Stone’s  thesis  [72]  show  two  different  ways  to  do  it).  Such  a  cycle  does  not  occur,  however,  at 
the  signature  level;  signature-level  validity  depends  only  on  constructor-level  validity  and  kind-level 
validity,  both  of  which  have  already  been  proven. 

Proposition  4.1.4  (Reflexivity) 

If  A  h  S  sig,  then  A  h  S  =  S  and  A  h  S  <  S. 

®The  singleton  signature  macro  also  preserves  the  equivalence/subtyping  relationships  of  its  arguments,  but  it  is 
easier  to  prove  this  later  (see  Proposition  4.1.9). 
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Proposition  4.1.5  (Validity) 

If  A  h  Si  =  S2  or  A  h  Si  <  S2,  then  A  h  Si  sig  and  A  h  S2  sig. 

Proposition  4.1.6  (Symmetry  and  Transitivity  of  Signature  Equivalence) 

1.  If  A  h  Si  =  S2,  then  A  h  S2  =  Si. 

2.  If  A  h  Si  =  S2  and  A  h  S2  =  S3,  then  A  h  Si  =  S3. 

Proposition  4.1.7  (Antisymmetry  and  Transitivity  of  Signature  Subtyping) 

1.  A  h  Si  =  S2  if  and  only  if  A  h  Si  <  S2  and  A  h  S2  <  Si. 

2.  If  A  h  Si  <  S2  and  A  h  S2  <  S3,  then  A  h  Si  <  S3. 

Proposition  4.1.8  (Functionality) 

Suppose  A'  h  7i  =  72  ;  A. 

1.  If  A  h  S  sig,  then  A'  h  71S  =  72S. 

2.  If  A  h  Si  =  S2,  then  A'  h  71S1  =  72S2. 

3.  If  A  h  Si  <  S2,  then  A'  h  71S1  <  72S2. 

The  proofs  of  the  following  properties  of  singleton  and  transparent  signatures  are  completely 
analogous  to  the  proofs  of  Propositions  3.1.12  and  3.1.14  given  in  Section  3.1.5.  The  only  sub¬ 
stantively  new  cases  are  the  type-specification  signature  [K],  for  which  the  proof  follows  directly 
from  the  propositions  just  named,  and  the  unitary  signatures,  for  which  the  proof  is  trivial  because 
Ss(C)  =  S  when  S  is  unitary.  The  proofs  implicitly  make  use  of  the  fact  that  Fst  commutes  with 
the  singleton  signature  macro  (Proposition  4.1.3  above). 

Proposition  4.1.9  (Singleton  and  Transparent  Signature  Rules) 

1.  If  A  h  S  sig  and  A  h  C  :  Fst(S),  then  A  h  5s(C)  <  S. 

2.  If  A  F  S  sig  and  AFC:  Fst(S),  then  A  F  5s(C)  =  §. 

3.  If  A  F  Si  <  S2  and  A  F  Ci  =  C2  :  Fst(Si),  then  A  F  5si(Ci)  <  332(02). 

4.  If  A  F  Si  =  S2  and  A  F  Ci  =  C2  :  Fst(Si),  then  A  F  Ss,(Ci)  =  332(02)- 

5.  If  A  F  Si  <  S2,  then  Si  is  transparent. 

6.  33(0)  is  transparent. 

7.  S  is  transparent  if  and  only  if  Fst(S)  is  transparent. 

Proof:  By  induction  on  the  size  of  the  given  signature(s). 

1.  •  Oase;  S  is  unitary.  Trivial,  by  reflexivity. 

•  Oase:  S  =  |K].  By  Proposition  3.1.12,  A  F  3k(0)  <  K,  so  A  F  |3k(0)]  <  |K]. 

•  Oase:  S  =  SX:S'.S". 

(a)  By  inversion,  A  F  S'  sig  and  A,  X‘^:Fst(S')  F  S"  sig. 

(b)  Since  A  F  ttiO  :  Fst(S'),  by  induction  A  F  33'(7riO)  <  S', 

(c)  and  by  Substitution,  A  F  S"[7ri0/X'^]  sig. 
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(d)  Since  A  h  7r2C  :  Fst(S")[7riC/X'^],  by  induction  A  h  -5s"[7riC/x^]('^2C)  <  S" [vri C/X'^] . 

(e)  By  Proposition  3.1.12,  A,X'^:Spst(g;)(7riC)  h  ttiC  =  X'^  :  SFst(S')(^i^)- 

(f)  By  Functionality,  A,  X^:Fst(Ss'(7riC))  h  S"[7riC/X^]  <  S". 

(g)  Thus,  A  hSs'(vriC)  xSs^,[,,c/xc](vr2C)  <  SXiS'.S". 

•  Case:  S  =  nX;S'.S". 

(a)  Since  A,X":Fst(S')  h  S"  sig,  and  A,X":Fst(S')  h  C(X")  :  Fst(S'0, 

(b)  by  induction  A,X^:Fst(S')  H  Ss"(C(X^))  <  S". 

(c)  Thus,  A  h  nX:S'.Ss//(C(X^))  <  BXiS'.S". 

2.  •  Case;  S  is  unitary.  Trivial,  by  reflexivity. 

•  Case:  S  =  [KJ.  By  Proposition  3.1.14,  A  h  Sik(C)  =  K,  so  A  h  [Sk(C)]  =  |IK]. 

•  Case:  S  =  XX;S'.§". 

(a)  By  inversion,  A  h  S'  sig  and  A, X‘^:Fst(S')  h  S"  sig. 

(b)  Since  A  h  ttiC  :  Fst(S'),  by  induction  A  h  S§/(7riC)  =  S', 

(c)  and  by  Substitution,  A  h  S"[7riC/X'^]  sig. 

(d)  Since  A  h  7r2C  :  Fst(S")[7riC/X'^],  by  induction  A  h  S§"[7riC/x^]('^2C)  =  S"[7riC/X'^]. 

(e)  By  Proposition  3.1.12,  A, X'^;SFst(S')('^iC)  F  ttiC  =  X*^  ;  SFst(S')('^iC^)- 

(f)  By  Functionality,  A,  X‘^:Fst(Ss'(^iC))  F  S"[7riC/X'^]  =  S". 

(g)  Thus,  A  F  Ss/(7riC)  x  %/[^iC/X"](^2C)  =  SX:S'.S". 

•  Case:  S  =  nX;S'.S". 

(a)  Since  A,XFFst(S')  F  S"  sig,  and  A,XFFst(S')  F  C(X")  :  Fst(S"), 

(b)  by  induction  A,XFFst(S')  F  Ss»(C(X"))  =  S". 

(c)  Thus,  A  F  nX:S'.Ss//(C(X^))  =  nX:S'.S". 

3.  •  Case;  Si  and  S2  are  unitary.  Trivial,  by  assumption. 

•  Case:  Si  =  |KJ.  By  Proposition  3.1.12,  A  FSki(Ci)  <Sk2(C2), 
so  A  F  |Ski(Ci)]  <  |Sk2(C2)1- 

•  Case:  Si  =  SX:S'.S^ 

(a)  By  inversion,  A  F  S'p  <  S2  and  A, X'^:Fst(S'F)  F  S'/  <  S'/. 

(b)  Since  A  F  vriCi  =  7riC2  :  Fst(S/),  by  induction  A  F  Ss/^(7riCi)  <  Sg^(7riC2), 

(c)  and  by  Functionality,  A  F  S/[7riCi/X'^]  <  S'2'[7riC2/X‘^]. 

(d)  Since  A  F  7r2Ci  =  7r2C2  :  Fst(S/)[7riCi/X^], 

(e)  by  induction  A  F  Sg»[^jCi/x-](7r2Ci)  <  Sg»[^^c2/x-]  (7!'2C2). 

(f)  Thus,  A  FSg/(7riCi)  x  Sg»[^jCi/x^](7’'2Ci)  <  Sg^(7riC2)  x  Sg»[^jC2/X"](^2C2). 

4.  By  Antisymmetry,  Part  3  of  this  proposition,  and  Part  4  of  Proposition  4.1.3. 


5-7.  Straightforward. 
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Signature  phase-splitting:  S  |a:K.C] 

1  |a:l.unit]  |K]  [a:K.unit]  [C]  [a;l.C] 

_ Si  ^  |X^:Ki.CiI  S2  ^  [a2:K2.C2] _ 

SX:Si.S2  ^  |a:(SX^:Ki.K2).Ci[7ria/X"]  x  C2[7ria/X^][7r2a/a2]l 
Si  ^  lX^:Ki.Cil  S2  ^  Ia2:K2.C2l 
nt°tX:Si.S2  ^  [a:(nX^;Ki.K2).VX^:Ki.Ci^C2[a(X")/a2]l 
Si  ^  [X'Ki.CiI  S2  ^  [«2:K2.C2] 
nP"^X:Si.S2  ^  |a:l.VX^;Ki.Ci  ^3a2:K2.C2l 

^S^  =  3a:K.C,  where  S  ^  |a:K.C| 

Figure  4.6;  Signature  Phase-Splitting  and  Definition  of  Package  Type 


4.1.4  Signature  Phase-Splitting 

In  this  section,  I  define  a  so-called  “phase-splitting”  translation  from  the  signature  language  into 
the  type  structure  of  the  core  language,  and  show  that  it  is  sound  and  preserves  equivalence 
and  subtyping  relations.  The  phase-splitting  translation  shown  in  Figure  4.6  takes  the  form  of 
a  judgment  S  =1  |a:K.C],  where  S  is  the  signature  being  translated,  K  represents  the  “static”  part 
of  S  {i.e.,  the  specifications  of  S’s  type  components)  and  C  represents  the  “dynamic”  part  of  the 
signature  (i.e.,  the  specihcations  of  S’s  value  components),  which  may  refer  to  the  type  components 
through  the  constructor  variable  a.  Note  that  the  static  part  K  is  precisely  Fst(S).  Figure  4.6  also 
defines  the  “package  type”  (|S^  to  be  the  existential  type  formed  from  packaging  together  the  static 
and  dynamic  parts  of  S.  Package  types  will  be  used  in  the  next  section  to  classify  modules  that 
have  been  pack’ed  as  core-language  terms. 

The  phase-splitting  translations  of  unit,  kind  and  type  signatures  are  all  self-explanatory.  The 
translations  of  the  remaining  signatures®  are  easiest  to  think  of  in  terms  of  how  they  guide  the 
phase-splitting  of  modules,  which  will  be  formalized  in  Section  4.2.7.  For  a  module  M  of  pair 
signature,  the  translation  joins  the  static  parts  of  M’s  first  and  second  components  as  a  pair  of 
constructors,  and  joins  the  dynamic  parts  as  a  pair  of  terms.  For  a  total  functor  F  of  signature 
n'^°'^X:Si.S2,  the  fact  that  “total”  here  means  separably  total”  tells  us  that  the  static  part  of  F’s 
result  only  depends  on  the  static  part  of  its  argument,  so  the  static  part  of  F  itself  is  a  constructor 
function  of  kind  nX'’:Fst(Si).Fst(S2).  The  dynamic  part  of  F’s  result,  however,  may  depend  on 
both  the  static  and  dynamic  parts  of  its  argument,  so  F’s  dynamic  part  is  a  polymorphic  function 
taking  both  a  type  and  a  value  argument.  When  F  is  a  partial  functor,  the  static  part  of  its  result 
cannot  be  hoisted  out,  because  it  may  depend  on  effectful  operations  that  produce  different  results 
at  each  application  of  F.  Correspondingly,  F  is  translated  as  a  polymorphic  function  returning 
an  existential  package  whose  static  part  is  unknown.  Note  that  the  result  type  of  this  function  is 
precisely  (IS2D. 

The  following  proposition  states  a  number  of  properties  of  signature  phase-splitting,  namely 

®The  rules  for  pair  and  total  functor  signatures  follow  exactly  the  non-standard  signature  equivalence  rules  em¬ 
ployed  by  Harper,  Mitchell  and  Moggi  in  their  phase-distinction  calculus  [30]. 
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that:  (1)  it  commutes  with  substitution,  (2)  the  static  part  of  S  is  precisely  Fst(S),  (3)  well-formed 
signatures  phase-split  to  well- formed  results,  (4)  equivalent  signatures  phase-split  to  equivalent 
results,  and  (5)  if  Si  is  a  subtype  of  S2,  then  the  dynamic  parts  of  the  signatures  are  equivalent, 
but  Fst(Si)  is  only  a  subkind  of  Fst(S2). 

Part  5,  which  I  need  in  order  to  prove  soundness  of  module  phase-splitting  in  Section  4.2.7,  is 
what  motivates  my  restrictive  definition  of  functor  subtyping.  Specifically,  for  any  functor  signature 
S  =  n'^X:Si.S2,  the  static  part  of  Si  leaks  into  the  dynamic  part  of  S,  so  the  dynamic  parts  of  two 
functor  signatures  will  only  be  equivalent  if  their  argument  signatures  have  equivalent  static  parts. 
This  condition  will  not  be  met  if  the  argument  signatures  are  merely  in  a  contravariant  subtyping 
relationship.  In  the  case  that  S  is  partial,  the  static  part  of  S2  leaks  into  the  dynamic  part  of  S  as 
well,  so  the  dynamic  parts  of  two  partial  functor  signatures  will  only  be  equivalent  if  their  result 
signatures  have  equivalent  static  parts.  This  condition  will  not  be  met  if  the  result  signatures  are 
merely  in  a  covariant  subtyping  relationship. 

It  is  worth  noting  that  if  the  core  language  supported  subtyping  in  addition  to  subkinding, 
and  if  Part  5  were  weakened  to  only  require  that  Ci  be  a  subtype  of  C2,  then  the  restrictions  I 
have  imposed  on  functor  subtyping  could  be  avoided.  For  simplicity,  however,  I  have  chosen  not  to 
introduce  subtyping  into  the  core  language. 

Proposition  4.1.10  (Soundness  and  Other  Properties  of  Signature  Phase-Splitting) 

1.  If  S  ^  |a:K.C],  then  7S  ^  laiyK.yC]. 

2.  If  S  ^  |a:K.C],  then  K  =  Fst(S). 

3.  If  A  h  S  sig,  then  A  h  :  T. 

4.  If  A  F  Si  =  S2,  then  A  h  =  (82^  :  T. 

5.  If  A  h  Si  <  S2  and  Si  |a:Ki.Ci]  and  S2  =1  |a:K2.C2|, 
then  A  h  Ki  <  K2  and  A,  a:Ki  h  Ci  =  C2  :  T. 

Proof:  By  straightforward  induction  on  the  size  of  the  given  signature(s).  ■ 


4.2  Modules 

4.2.1  Syntax 

The  syntax  of  modules  is  given  in  Figure  4.7,  along  with  extensions  to  the  syntax  of  terms.  Dynamic 
contexts  are  also  extended  with  a  new  binding  form  that  assigns  signatures  to  module  variables. 
Figure  4.8  illustrates  how  some  of  the  module  constructs  correspond  to  module  expressions  one 
finds  in  dialects  of  ML. 

The  unit  module  containing  no  bindings  is  written  ().  The  constructor  module  [C]  contains 
a  single  binding  of  a  constructor  component  defined  as  C.  The  term  module  [e]  contains  a  single 
binding  of  a  value  component  defined  by  evaluating  the  term  e.  The  new  term-level  construct 
Term(M)  allows  one  to  extract  the  single  value  component  from  a  module  M  of  signature  |C]. 

The  pair  module  (X  =  Mi,M2)  consists  of  a  pair  of  modules,  wherein  the  second  module  M2 
may  refer  to  the  first  (or  rather,  to  the  result  of  evaluating  the  first)  by  the  variable  X.  As 
with  pair  signatures,  the  ML  analogue  for  (X  =  Mi,M2)  shown  in  Figure  4.8  is  not  quite  precise 
because  projections  from  modules  are  done  here  by  position — ttiM  and  7r2M  are  the  first  and  second 
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Purity  Classifiers 

Terms 

Modules 


Projectible  Modules 
Dynamic  Contexts 


k::=  P  I  I 

e  ::=  •  •  •  |  Term(M)  |  pack  M  as  S 
M,N,F  ::=  X  |  ()  |  [C]  |  [e]  |  (X  =  Mi,M2)  |  vr^M  | 

At°tX:S.M  I  Ft°t(M)  |  AP^''(X:Si):S2.M  |  FP^''(M)  | 

M  :>K  S  I  purify(M)  |  unpack  M  as  S  |  let  X  =  M'  in  (M  :  S) 
M,N,F  ::=  X  |  ()  |  [C]  |  [e]  |  (X  =  Mi,M2)  |  tt^M  | 

At°tX:S.M  I  r°t(M)  I  AP"''(X:Si):S2.M 
F  :;=  •••I  r,X:S 


Figure  4.7;  Syntax  of  Modules 


0 

[C] 

[e] 

(X  =  Mi,M2) 


AP^^(X:Si):S2.M 


struct  end 

struct  type  t  =  C  end 
struct  val  x  =  e  end 
struct 

structure  X  =  Mi 
structure  Y  =  M2 

end 

functor  (X  :  Si)  ->  M 
functor  (X  :  Si)  :>  S2  “>  M 


Figure  4.8;  Correspondence  With  ML  Modules 


projections  of  M — whereas  in  ML  they  are  done  by  name.  Correspondingly,  X  is  alpha-convertible 
in  (X  =  Mi,M2),  but  changing  X  to  X'  in  the  ML  analogue  results  in  a  module  with  a  different 
signature.  I  will  sometimes  write  (Mi,  M2)  as  shorthand  when  X  0  FV(M2). 

Total  functors  are  written  A''°''X;S.M,  where  X  is  the  argument  variable,  S  the  argument  signa¬ 
ture,  and  M  the  functor  body.  The  application  of  a  total  functor  F  to  an  argument  M  is  written 
F'-°'-(M).  The  syntax  for  partial  functor  introduction  and  elimination  is  similar,  except  that  the 
partial  functor  introduction  form  AP^''(X;Si);S2.M  also  includes  a  result  signature  S2.  The  result 
signature  is  needed  in  order  to  ensure  that  modules  have  principal  signatures.  If  a  result  signature 
were  not  required,  then  AP^''X;Si.M  could  be  assigned  a  range  of  different  signatures  nP^''X;Si.S2, 
with  S2  ranging  over  different  signatures  for  M.  Even  if  M  has  a  principal  signature  Smj  the 
signature  nP^''X;Si.SM  would  not  be  principal  for  Ap^''X;Si.M  because  partial  functor  subtyping 
is  invariant  in  the  result  signature.  In  practice,  however,  this  is  not  an  important  issue — in  the 
language  design  I  present  in  Part  III,  the  result  signatures  of  partial  functors  are  simply  inferred. 

Sealed  module  expressions  are  written  M  ;  >«  S,  where  /t  is  a  purity  classifier  that  can  either  be  P 
for  “pure”  or  I  for  “impure.”  Recall  that  we  are  not  differentiating  here  between  (static)  purity  and 
separability,  so  P  and  I  may  also  be  read  as  “separable”  and  “inseparable,”  respectively.  M  ;>p  S 
corresponds  to  the  basic  form  of  sealing,  while  M  ;>i  S  corresponds  to  the  impure  form  of  sealing. 
The  motivation  for  these  two  forms  was  described  in  Section  2.1.5.  As  noted  in  Section  2.1.6, 
M  ;>i  S  may  be  encoded  via  partial  functors  as  follows;  (AP^'^(X;1);S.M)(()).  I  am  not  aware  of 
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any  similar,  purely  syntactic  encoding  of  basic  sealing,  although  Shan  [67]  has  described  a  rather 
complex  global  program  transformation  that  effectively  translates  uses  of  basic  sealing  into  uses  of 
impure  sealing. 

As  I  explained  in  Section  2.1.7,  modules  that  can  be  given  transparent  signatures  should  be 
considered  pure.  For  simplicity,  however,  my  module  typing  judgment  implements  this  semantics 
somewhat  lazily:  it  will  not  necessarily  consider  all  transparent  modules  to  be  pure,  but  if  one 
wants  a  transparent  module  M  to  be  considered  pure,  one  can  indicate  this  by  writing  purify(M). 
The  purify  expression  has  no  run-time  effect,  it  merely  forces  the  module  to  be  considered  pure. 

The  new  term-level  construct  pack  M  as  S  and  module-level  construct  unpack  e  as  S  serve  as 
coercions  between  modules  and  terms.  The  former  packages  a  module  M  of  signature  S  as  a  term 
of  package  type  (|SD,  and  the  latter  unpackages  a  term  e  of  type  (jS^  into  a  module  of  signature  S.^ 
This  enables  support  for  first-class  module  programming  when  desired. 

Lastly,  I  also  include  a  let-expression  at  the  module  level,  let  X  =  Mi  in  (M2  :  S).  The  signature 
annotation  S  is  present  to  ensure  that  the  let  module  has  a  principal  signature.  (This  issue  will 
be  discussed  further  in  Section  4.2.6.)  The  type  system  treats  let  X  =  Mi  in  (M2  :  S)  as  if  its 
body  contained  an  instance  of  basic  sealing  (i.e.,  M2  :>?  S).  I  will  sometimes  omit  the  S  when  it 
is  obvious  from  context  what  it  should  be. 

4.2.2  Projectible  Modules 

Figure  4.7  also  defines  a  syntactic  subclass  of  projectible  modules,  written  M.  The  criterion  here  for 
projectibility  is  based  on  the  analysis  of  Chapter  2:  projectible  modules  are  essentially  those  mod¬ 
ules  which  are  pure/separable  and  which  do  not  contain  any  uses  of  sealing.  While  this  description 
is  mostly  accurate,  it  does  not  tell  the  complete  story. 

First  of  all,  I  only  treat  as  projectible  those  modules  which  the  type  system  considers  pure 
without  the  aid  of  purify  coercions.  The  reason  for  this  is  primarily  technical:  I  want  to  be  able 
to  extract  the  static  part  of  a  projectible  module — a  constructor  comprising  the  module’s  type 
components — in  a  purely  syntactic,  context-free  manner,  and  for  certain  morally  projectible  mod¬ 
ules  this  is  not  possible.  For  example,  suppose  that  X  is  a  variable  bound  in  the  context  with  a 
partial  functor  signature  nP^''Y:Si.S2,  where  S2  is  transparent.  Applying  X  to  some  projectible 
module  M  results  in  a  transparent  module,  which  is  morally  projectible.  However,  there  is  no  way 
to  tell  that  XP^''(M)  is  projectible  (or  even  pure),  and  certainly  no  way  to  extract  its  static  part, 
without  knowing  the  signature  that  X  is  bound  with.  I  argue  that  not  being  able  to  project  types 
from  transparent  modules  like  XP^'’(M)  does  not  result  in  any  fundamental  loss  of  expressiveness 
anyway — for  any  type  component  t  in  a  transparent  module  N,  the  signature  of  N  will  contain  a 
specification  type  t  =  C  that  indicates  a  well-formed  type  C  to  which  N.t  is  equivalent. 

Second,  what  does  it  mean  for  a  functor  to  be  projectible?  The  answer  is  that  the  definition  of 
projectibility  in  this  calculus  is  a  bit  more  general  than  the  definition  given  at  the  start  of  Chapter  2: 
a  module  is  considered  projectible  in  this  language  if  one  may  extract  types  from  it,  not  necessarily 
by  direct  projection.  In  the  case  of  a  functor,  extracting  types  means  first  applying  the  functor  and 
then  projecting  (or  extracting)  types  from  the  result.®  Hence,  total  functors  are  projectible  so  long 
as  their  bodies  are  projectible,  and  total  functor  applications  are  projectible  so  long  as  the  functor 
and  the  argument  are  both  projectible. 

Given  this  generalization  of  projectibility,  one  may  be  surprised  to  find  that  all  partial  functor 

’^The  package  type  (|SD  was  defined  above,  in  Figure  4.6,  in  terms  of  the  existing  type  structure  of  the  core  language. 

®Perhaps  “extractability”  would  have  been  a  better  word  to  use  than  “projectibility”  from  the  beginning,  but  the 
latter  has  the  advantage  of  being  the  same  term  that  we  used  in  Dreyer  et  al.  [12]. 
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Fst(X) 

def 

X" 

Fst(()) 

def 

0 

Fst([C]) 

def 

c 

Fst([e]) 

def 

0 

Fst((X  =  Mi,M2)) 

def 

(X^  =  Fst(Mi),Fst(M2)) 

Fst(7rjM) 

def 

7r*(Fst(M)) 

Fst(A^°^X;S.M) 

def 

AX^;Fst(S).Fst(M) 

Fst(Ft°t(M)) 

def 

Fst(F)(Fst(M)) 

Fst(AP"^(X;Si);S2.M) 

def 

0 

Figure  4.9;  Extracting  the  Static  Part  of  a  Projectible  Module 


expressions  Af’^'^(X:Si):S2.M  are  considered  projectible.  The  reason  for  this  is  simple.  The  type 
system  will  never  allow  a  partial  functor  expression  to  be  applied  inside  a  pure  module,  let  alone 
a  projectible  module,  so  any  appearance  that  a  partial  functor  makes  inside  a  pure/projectible 
module  expression  will  be  useless  as  far  as  the  extraction  of  type  components  is  concerned.  Since 
partial  functors  can  only  make  useless  appearances  inside  projectible  modules,  there  is  no  good 
reason  to  banish  them.®  The  same  goes  for  the  unit  module  ()  and  term  module  [e],  neither  of 
which  has  any  type  components  that  could  be  extracted.  Note  that  these  three  module  forms — unit, 
term  and  partial  functor — are  precisely  those  which  inhabit  the  “unitary”  signatures  S  for  which 
Fst(S)  is  the  unit  kind. 

As  explained  in  Section  2.2.3,  I  have  chosen  in  this  calculus  not  to  introduce  any  new  type- 
level  construct  for  projecting  types  from  modules.  Instead,  I  define  a  meta-level  function  Fst(M) 
(shown  in  Figure  4.9)  that  computes  a  type  constructor  representing  the  static  part  of  M.  The  type 
components  of  M  may  then  be  projected  (or,  more  generally,  extracted)  from  Fst(M),  rather  than 
from  M  itself.  Given  the  above  discussion,  the  definition  of  Fst(M)  should  be  fairly  self-explanatory; 
the  only  unusual  cases  are  the  modules  M  for  which  Fst(M)  is  always  unit,  and  these  are  precisely 
the  modules  from  which  no  type  components  can  be  extracted. 

The  definition  of  Fst(M)  ensures  that,  when  checking  equivalence  of  types  projected  from  mod¬ 
ules,  arguments  to  total  functors  are  compared  via  static  equivalence.  For  example,  supposing 
that  the  result  signature  of  a  functor  F  were  |T],  the  types  Fst(F'^°'^(Mi))  and  Fst(F'^°'^(M2))  will  be 
equivalent  whenever  Fst(Mi)  and  Fst(M2)  are  equivalent,  i.e.,  whenever  Mi  and  M2  have  equivalent 
type  components. 


®For  those  familiar  with  the  previous  version  of  this  type  system  (Dreyer,  Crary  and  Harper  [12],  described  in 
Section  2.3):  it  is  worth  noting  here  that  the  desire  to  treat  partial  fnnctor  expressions  as  projectible  is  the  only 
motivation  for  why  DCH’s  strange  “S”  purity  class  exists.  In  the  DCH  type  system,  a  module  is  only  considered 
projectible  if  it  is  pure  and  free  of  any  sealing.  Thus,  while  DCH  considers  all  functors  to  be  pure  (because  they 
are  values),  it  considers  a  partial  functor  A'^^'^(X:Si):S2.M  to  be  projectible  only  if  the  body  M  is  also  free  of  sealing. 
However,  since  this  is  a  partial  functor  we  are  talking  about,  M  is  still  permitted  to  be  impure.  The  “S”  purity  class 
describes  precisely  those  modules  that  are  potentially  impure  but  free  of  sealing,  so  A'’^'^(X:Si):S2.M  is  projectible  in 
DCH  if  and  only  if  M  can  be  given  purity  classification  S.  My  present  approach,  which  is  to  just  treat  all  partial 
functor  expressions  as  projectible,  seems  much  simpler. 
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4.2.3  Static  Semantics 

Figure  4.10  shows  the  inference  rules  for  the  judgment  of  well-formed  modules,  as  well  as  new  rules 
for  the  judgments  of  well-formed  terms  and  dynamic  contexts.  The  module  judgment  F  h  M  S 
says  that  M  has  signature  S  and  purity  k.  If  k  =  P,  then  M  is  pure;  if  k  =  I,  then  M  may  be 
impure.  I  will  sometimes  make  use  of  meets  (□)  and  joins  (U)  in  the  two-point  lattice  P  E  I- 

As  I  have  extended  the  syntax  of  dynamic  contexts,  I  will  also  extend  the  erasure  function 
mapping  dynamic  contexts  to  static  contexts  as  follows: 

Fst(r,X;S)  =  Fst(r),XEFst(S) 

As  in  the  term  well-formedness  judgment  of  Chapter  3,  some  of  the  inference  rules  in  Figure  4.10 
refer  in  their  premises  to  the  judgments  involving  constructors,  kinds  and  signatures,  except  with 
a  dynamic  context  F  in  place  of  a  static  context  A.  The  meaning  of  these  premises  is  the  same  one 
given  before  by  Definition  3.2.1,  namely  that  F  h  is  shorthand  for  the  conjunction  of  F  h  ok  and 
Fst(F)  h  J. 

Some  notational  conveniences:  Since  module  variables  X  cannot  appear  directly  in  signatures 
(only  their  static  parts  X'^  can),  S[M/X]  should  be  taken  as  shorthand  for  S[Fst(M)/X‘^].  Similarly, 
the  notation  Ss(M)  is  shorthand  for  the  signature  5s(Fst(M)),  which  classifies  precisely  those 
modules  of  signature  S  which  are  statically  equivalent  to  M,  i.e.,  whose  static  parts  are  equivalent 
to  Fst(M). 

Now  for  the  rules,  many  of  which  should  appear  very  similar  to  the  rules  for  well-formed 
constructors.  Rules  84-90  are  completely  straightforward.  For  Rule  90,  recall  that  the  purity 
of  [e]  relates  to  the  module’s  lack  of  type  components  and  does  not  imply  anything  about  the 
computational  purity  of  the  term  e.  Rules  91,  92  and  101  say  that  pairs,  first  projections  and 
let-expressions  are  as  pure  as  their  component  modules. 

Rule  93,  however,  requires  that  second  projections  only  be  made  from  projectible  (and  thus 
pure)  modules.  The  reason  for  this  restriction  is  that  the  signature  of  7r2M  is  formed  by  substituting 
Fst(7riM)  in  for  X”’  in  the  signature  of  M’s  second  component.  Fst(7riM)  is  only  a  valid  operation 
when  ttiM  is  a  projectible  module,  which  in  turn  implies  that  M  itself  must  be  projectible.  One 
potential  way  to  ameliorate  this  restriction  would  be  to  require  that  the  signature  of  M  be  a 
non-dependent  pair  signature  S'  x  S".  The  signature  of  7r2M  would  then  be  simply  S",  requiring 
no  substitutions.  Unfortunately,  as  I  will  explain  in  Section  4.2.6,  this  approach  runs  afoul  of 
something  called  the  “avoidance  problem.”  In  practice,  though,  this  restriction  does  not  seem  to 
be  a  major  issue  since  all  existing  ML  dialects  impose  it. 

Rules  94  and  96  say  that  total  and  partial  functors  are  pure  expressions  (of  course,  because  they 
are  values),  but  that  total  functors  must  in  addition  have  pure  bodies.  Rule  95  says  that  a  total 
functor  application  F''°''(M)  is  as  pure  as  F  and  M  are,  whereas  Rule  97  says  that  partial  functor 
applications  FP^''(M)  are  always  considered  impure.  Note  that  in  both  cases  the  functor  argument 
M  is  required  to  be  projectible,  for  the  same  reason  that  second  projections  are  only  permitted 
from  projectible  modules.  The  signature  of  F’'(M)  requires  Fst(M)  to  be  substituted  for  X*^  in  the 
result  signature  S",  which  is  only  valid  if  M  is  projectible. 

Rule  98  joins  the  rules  for  basic  and  impure  sealing  into  one.  When  k  =  P,  the  sealed  module 
M  :>K  S  has  the  same  purity  as  M;  when  k  =  1,  the  sealed  module  will  be  impure  regardless.  In 
either  case,  the  sealed  module  does  not  belong  to  the  syntax  of  projectible  module  expressions. 
Rule  99  says  that  purify(M)  is  well-formed  and  pure,  regardless  of  M’s  inferred  purity  level,  so  long 
as  M  can  be  given  a  transparent  signature. 

Rule  100  says  that  unpacking  a  term  of  package  type  into  a  module  expression  results  in  a 
potentially  impure  module,  because  the  type  components  of  the  module  may  depend  on  core- 
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New  rules  for  well-formed  dynamic  contexts:  F  h  ok 


r  h  s  sig 

r,X:S  hok 


New  rules  for  well-formed  terms:  F  h  e  :  C 


F  h  M  |C] 

F  h  Term(M)  :  C 


(85) 


(84) 


F  h  M  S 


F  h  pack  M  as  S  :  (|S^ 


(86) 


Well-formed  modules:  F  h  M  S 


F  h  ok  X:S  £  F 
F  h  X  :p  S 


(87) 


F  h  ok 
F  h  0  :p  1 


(88) 


F  h  C  :  K 
F  h  [C]  :p  IKI 


(89) 


F  h  e  :  C 


(90) 


FhM':«S'  F,X:S' h  M"  S" 
F  h  (X  =  M',M")  SXiS'.S" 

F,X:S'  h  M  :p  S" 


(91) 


F  h  M  SXrS'.S" 
F  h  TTiM  S' 


(92) 


F  h  [e]  :p  [Cl 

F  h  M  :p  SXiS'.S" 

F  h  vrsM  :p  S"[7riM/X] 


(93) 


F  h  At°tX:S'.M  :p  nt°tX:S'.S 
F,X:S'hM:i  S" 

F  h  AP"^(X:S'):S".M  :p  nP"^X:S'.S" 
F  h  M  S 


.  (94) 

(96) 
(98) 


F  h  F  nt°tX:S'.S"  F  h 


S' 


F  h  Ft°t(M)  S"[M/X] 
F  h  F  nP"^X:S'.S"  F  h 


(95) 

pS' 


F  h  FP^^(M)  :i  S"[M/X] 
F  h  M  § 


(97) 


Fh  (M  :>,  S)  S 


F  h  purify(M)  :p  S 


(99) 


F  h  e  :  ^S[  F  h  S  sig 

F  h  unpack  e  as  S  :i  S 
F  h  M  :p  S 


(100) 


F  h  M'  S'  F,  X:S'  h  M  S  F  h  S  sig 


F  h  let  X  =  M'  in  (M  :  S)  S 


(101) 


F  h  M  :p  5g(M) 


(102) 


F  h  M  :p  S 
F  h  M  It  S 


(103) 


F  h  M  S'  F  h  S'  <  S 
F  h  M  S 


(104) 


Figure  4.10;  Inference  Rules  for  Modules 


language  computational  effects.  Note  that  the  second  premise  of  the  rule  is  needed  because  the 
well-formedness  of  the  type  (]SD  does  not  necessarily  imply  that  S  is  a  well- formed  signature. 

Rule  102  implements  selfification,  also  known  as  signature  strengthening.  It  says  that  a  pro- 
jectible  module  M  with  signature  S  may  also  be  assigned  the  (potentially)  more  precise  signature 
Ss(M).  This  rule  is  critical  to  ensuring  principal  signatures  for  modules.  It  is  primarily  useful 
when  M  is  a  variable  X.  For  example,  if  X  has  signature  SYilTj.ly^],  which  corresponds  to  the 
ML  signature  sig  type  t  ;  val  v  :  t  end,  then  the  selfification  rule  assigns  X  the  more  precise 
|S(7riX'^)]  X  [ttiX'^],  which  corresponds  in  ML  to  sig  type  t  =  X.t  ;  val  v  :  X.t  end.  This 
“selfified”  signature  encapsulates  all  that  is  known  statically  about  X. 

Finally,  Rule  103  allows  the  purity  of  a  module  to  be  forgotten,  and  Rule  104  implements 
subsumption. 
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4.2.4  Declarative  Properties 

It  is  easy  to  check  that  the  declarative  properties  of  the  core  language  continue  to  hold  under  the 
extension  of  dynamic  contexts  with  module  variable  bindings,  and  that  all  the  structural  properties 
except  Substitution  apply  to  the  module  well-formedness  judgment  as  well.  Additionally,  we  have 
the  following  new  properties: 

Proposition  4.2.1  (Subderivations) 

Every  proof  of  ri,X:S,r2  b  77  contains  a  strict  subderivation  of  Ei  h  S  sig. 

Proposition  4.2.2  (Weakening) 

If  ri,X:S2,r2  b  J  and  Ei  b  Si  <  S2,  then  Ei,X:Si,E2  b  J. 


Proposition  4.2.3  (Fst(M)  Preserves  Well-Formedness) 

If  E  b  M  S,  then  E  b  M  :p  S  and  E  b  Fst(M)  :  Fst(S). 

Proof:  By  induction  on  derivations.  ■ 


Proposition  4.2.4  (Validity) 

If  E  b  M  Ik  S,  then  E  b  S  sig. 

Proof:  By  induction  on  derivations,  with  straightforward  uses  of  Proposition  4.2.3.  ■ 


4.2.5  Signature  Checking  and  Synthesis 

Figure  4.11  defines  a  signature  checking  algorithm  for  modules.  To  check  whether  a  module  M  has  a 
given  signature  S  and  purity  level  k,  the  algorithm  synthesizes  the  principal  signature  S'  and  minimal 
purity  level  k'  of  M,  and  checks  whether  S'  and  k'  are  smaller  than  S  and  k,  respectively.  Like 
the  kind  synthesis  algorithm,  the  signature  synthesis  algorithm  is  very  similar  to  the  declarative 
system,  except  that  (1)  it  expects  the  context  it  is  given  to  be  well-formed,  (2)  it  only  selfifies 
variables,  and  (3)  it  restricts  the  use  of  subsumption  to  functor  arguments  and  sealed  modules. 

Here  I  give  several  properties  of  signature  synthesis,  including  that  it  is  sound  and  complete, 
and  that  the  principal  signatures  of  projectible  modules  are  always  transparent.  This  last  fact 
comes  in  handy  in  proving  Part  3  of  the  completeness  theorem. 

Proposition  4.2.5  (Soundness  and  Other  Properties  of  Signature  Checking/Synthesis) 

Assume  E  b  ok. 

1.  If  E  b  M  S  or  E  b  M  S,  then  E  b  M  S. 

2.  If  E  b  M  =^Ki  Si  and  E  b  M  =^^2  S2,  then  Si  =  S2  and  ki  =  K2- 

3.  If  E  b  M  =^p  S,  then  S  is  transparent. 

4.  For  77  ranging  over  any  judgment  defined  in  Figure  4.11, 
if  E  b  77  and  E'  A  E  and  E'  b  ok,  then  E'  b  77. 


Proof:  By  straightforward  induction  on  the  algorithm. 
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Signature  checking:  F  h  M 


r  h  M  S'  r  h  S'  <  s  k'  uk 
r  h  M  s 


Signature  synthesis:  F  h  M 


X:S  G  F 


F  h  C  ^  K 


FhX^pSs(X)  FhO^pl  Fh[C]^plK] 


F  h  M'  S'  F,  X:S'  h  M"  S"  F  h  M 
F  h  (X  =  M',M")  XXiS'.S" 

FhS'sig  F,X:S'hM^pS" 

F  h  A^°^X:S'.M  ^p  nt°tX:S'.S" 

FhS'sig  F,X:S'hM^iS" 

F  h  AP"'(X:S'):S".M  ^p  nP"'X:S'.S" 

F  h  M  S'  F  h  S'  <  S  F  h  M 


XX:S'.S" 


F  h  e  ^  C 
F  h  [e]  ^p  [Cl 

F  h  M  ^P  SX:S'.S" 


F  h  TTiM  S'  F  h  TTaM  ^p  S"[7riM/X] 

F  h  F  nt°tX:S'.S"  F  h  M  ^P  S' 

F  h  Ft°t(M)  S"[M/X] 

F  h  F  nP"'X:S'.S"  F  h  M  ^P  S' 

F  h  FP"'(M)  S"[M/X] 


_  _ S_  F  h  S  sig  F  h  e  ^  ^S^ 

F  h  (M  :>K  S)  =^kUk'  S  F  h  purify(M)  ^p  S  F  h  unpack  e  as  S  =^i  S 

F  h  M'  S'  F,  X:S'  h  M  S"  F,  X:S'  h  S"  <  S  F  h  S  sig 
F  h  let  X  =  M'  in  (M  :  S)  S 


New  type  synthesis  rules:  F  h  e  C 


F  h  M 


ICl 


F  h  M 


F  h  Term(M)  ^  C  F  h  pack  M  as  S  ^  IS^ 


Figure  4.11:  Signature  Checking  and  Principal  Signature  Synthesis 


Theorem  4.2.6  (Completeness  of  Signature  Checking) 

1.  If  F  h  e  :  C,  then  F  h  e  ^  C. 

2.  If  F  h  M  S,  then  F  h  M  S. 

3.  If  F  h  M  ;p  S,  then  F  h  M  ^p  Ss(M). 

Proof:  By  induction,  first  on  the  structure  of  the  module  M  (or  term  e),  and  second  on  the 
structure  of  the  derivation  of  the  premise.  The  proof  of  Parts  1  and  2  are  by  cases  on  the  structure 
of  the  input  derivation  and  are  completely  straightforward,  but  I  will  write  out  most  of  the  cases 
anyway  (see  below).  There  are  only  two  cases.  Rules  91  and  101,  in  which  induction  is  applied  to 
a  derivation  that  is  not  a  subderivation  of  the  input  derivation.  It  is  these  cases,  however,  that 
necessitate  induction  first  on  the  structure  of  M. 

The  proof  of  Part  3  follows  easily  from  Part  2:  If  F  h  M  :p  S,  then  by  Part  2,  F  h  M  ^p  M,  where 
F  h  R  <  S  (and  R  is  transparent  due  to  Part  3  of  Proposition  4.2.5).  By  Soundness,  F  h  M  :p  R. 
Then,  by  Proposition  4.1.9,  F  h  R  =  Sir(M)  and  F  h  5ir(M)  <  Ss(M).  Thus,  by  Transitivity, 
F  h  R  <  Ss(M)  as  desired. 

•  Case:  Rules  55-67.  Same  as  in  proof  of  Proposition  3.2.6. 
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Case:  Rules  85-88.  Straightforward. 

Case:  Rule  89.  By  Proposition  3.1.16. 

Case:  Rule  90.  Straightforward. 

Case:  Rule  91. 

1.  By  induction,  PPM'  R',  where  P  h  R'  <  S'  and  k'  C  k. 

2.  By  Weakening,  r,X:R'  h  M"  S". 

3.  By  induction,  r,X:R'  h  M"  R^^  where  r,X:R'  h  R"  <  S"  and  k"  U  k. 

4.  Thus,  P  h  (X  =  M',M")  SX:R'.R", 

5.  and  P  h  SX:R'.R"  <  SX:S'.S",  and  k'  U  k”  C  k. 

Case:  Rule  92. 

1.  By  induction,  P  h  M  SX:R'.R",  where  P  h  R'  <  S',  r,X:R'  h  R"  <  S"  and  k'  C  k. 

2.  Thus,  T  h  ttiM  R'. 

Case:  Rule  93. 

1.  By  induction,  T  h  M  SX:R'.R",  where  T  h  R'  <  S'  and  r,X:R'  h  R"  <  S". 

2.  Thus,  T  h  7riM  :p  R'  and  T  h  7r2M  =^p  R"[7riM/X]. 

3.  By  Substitution,  T  h  R"[7riM/X]  <  S"[7riM/X]. 

Case:  Rule  94. 

1.  By  induction,  r,X:S'  h  M  ^p  R",  where  r,X:S'  h  R"  <  S". 

2.  Thus,  T  h  X^°^X:S'M  ^p  nt°tX:S'.R",  and  T  h  nt°tX:S'.R"  <  nt°tX:S'.S". 

Case:  Rule  95. 

1.  By  induction,  T  h  F  nt°tX:R'.R",  where  T  h  R'  =  S',  T,  X:R'  h  R"  <  S"  and  k'  C  k. 

2.  By  induction,  T  h  M  <^=p  S'  and  so  T  h  M  <^p  R'. 

3.  Thus,  T  h  Ft°t(M)  R"[M/X],  and  by  Substitution,  F  h  R"[M/X]  <  S"[M/X]. 

Case:  Rule  96. 

1.  By  induction,  F,X:S'  h  M  <^=i  S". 

2.  Thus,  F  h  AP"'(X:S'):S".M  ^p  nP^'X:S'.S". 

Case:  Rule  97. 

1.  By  induction,  F  h  F  nP"''X:R'.R",  where  F  h  R'  =  S',  F,  X:R'  h  R"  =  S"  and  k'  C  k. 

2.  By  induction,  F  h  M  <^=p  S'  and  so  F  h  M  <^p  R'. 

3.  Thus,  F  h  FP^''(M)  R"[M/X],  and  by  Substitution,  F  h  R"[M/X]  =  S"[M/X]. 

Case:  Rule  98. 

1.  By  induction,  F  h  M  R)  where  F  h  R  <  S  and  k"  C  k' . 
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2.  Thus,  r  h  M  : >K  S  =^kuk"  S,  and  k\J  k"  U  k\J  k' . 

•  Case:  Rule  98. 

1.  By  induction,  T  h  M  R;  where  T  h  R  <  S. 

2.  By  Proposition  4.1.9,  R  is  transparent. 

3.  Thus,  T  h  purify(M)  =^p  R. 

•  Case:  Rule  100.  Straightforward. 

•  Case:  Rule  101. 

1.  By  induction,  T  h  M'  R',  where  T  h  R'  <  S'  and  k'  C  k. 

2.  By  Weakening,  r,X:R'  h  M  S. 

3.  By  induction,  r,X:R'  h  M  R^^  where  r,X:R'  h  R"  <  S  and  k"  C  k. 

4.  Thus,  T  h  let  X  =  M'  in  (M  :  S)  =^k'uk"  S,  and  k'  U  k"  C  k. 

•  Case:  Rule  102.  By  induction,  using  Part  3. 

•  Case:  Rules  103  and  104.  Straightforward. 


The  soundness  and  completeness  of  the  signature  checking  algorithm  allow  us  to  observe  that 
sealed  module  expressions  are  truly  abstract  in  the  following  sense.  Suppose  a  well-formed  program 
contains  within  it  the  module  expression  M  :>«  S.  The  algorithm  regularizes  the  typing  derivation 
of  the  program  so  that  there  is  a  unique  subderivation  of  the  well-formedness  of  M  :>k  S.  The 
last  rule  applied  in  this  subderivation  is  Rule  98,  and  it  has  conclusion  T  h  (M  :>«,  S)  -.^uk'  S  and 
premise  T  h  M  :kZ  S,  where  T  is  some  suitable  context  in  which  M  is  well-formed.  Now,  for  any  other 
implementation  M'  of  S  for  which  T  h  M'  :k'  S,  we  can  clearly  swap  M'  :>«  S  in  for  M  :>«,  S  and 
the  program  will  still  be  well-formed.  Thus,  there  is  no  way  for  the  part  of  the  program  outside  of 
this  sealed  module  expression  to  depend  on  the  identities  of  any  type  components  that  are  specified 
opaquely  by  S,  as  they  may  differ  between  M  and  M'. 

Finally,  since  the  signature  checking  algorithm,  the  context  well-formedness  judgment  and  all 
the  signature  judgments  in  Figure  4.5  are  syntax-directed,  it  follows  easily  that  the  entire  type 
system  is  decidable. 

4.2.6  The  Avoidance  Problem 

The  type  system  for  ML  modules  that  I  have  presented  in  this  chapter  does  not  give  a  complete 
account  of  the  ML  module  system,  nor  is  it  intended  to.  Rather,  the  goal  of  this  type  system 
is  to  capture  what  I  believe  are  the  most  important  and  interesting  aspects  of  the  ML  module 
system — sealing,  functors  and  translucency — in  an  elegant  type-theoretic  framework.  In  addition, 
the  type  system  illustrates  that  it  is  easy  to  support  both  total  and  partial  functors,  and  both  the 
basic  and  impure  forms  of  sealing,  within  a  single  unified  language  design. 

There  are  several  features  of  ML  that  are  difficult  to  account  for  directly  in  type  theory  but  which 
will  be  dealt  with  formally  in  the  language  design  of  Part  III  using  elaboration  techniques.  Most  of 
these  features  are  syntactic  conveniences,  whose  practical  importance  should  not  be  discounted  but 
which  are  not  very  interesting  from  a  type- theoretic  point  of  view.  As  I  discussed  in  Section  4.1.2, 
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one  particularly  important  one  is  ML’s  notion  of  signature  matching,  which  is  considerably  more 
permissive  than  the  signature  subtyping  judgment  of  this  type  system. 

Another  one,  which  is  the  subject  of  this  section,  is  not  so  much  a  feature  of  ML  as  an  issue 
that  arises  in  a  number  of  different  guises  and  can  be  seen  as  affecting  the  typing  rules  for  several 
different  constructs  in  my  type  system.  Recall  that,  for  both  second  projections  7r2M  and  functor 
applications  F'^(M),  the  submodule  M  must  be  projectible  in  order  for  the  whole  module  to  be 
considered  well-formed.  One  way  to  address  this  restriction  is  to  support  a  variant  of  each  of 
these  constructs  that  permits  the  module  M  to  be  non-projectible,  even  impure,  at  the  expense 
of  requiring  a  signature  annotation.  In  other  words,  consider  extending  the  language  with  the 
constructs  (7r2M  :  S)  and  (F'^(M)  :  S),  for  both  of  which  the  principal  signature  will  be  S.  These 
annotated  constructs  are  in  fact  already  expressible  as  derived  forms: 

7r2(M):S  =  let  X  =  M  in  (7r2X  :  S) 

F^(M):S  =  let  Xi  =  F  in  let  X2  =  M  in  (Xi^(X2)  :  S) 

In  practice,  however,  the  signature  annotation  may  constitute  an  unacceptable  amount  of  syntactic 
overhead.  We  would  like  to  have  some  way  of  inferring  the  signature  S. 

Unfortunately,  it  is  not  always  possible  to  do  so.  As  the  above  derived  forms  illustrate,  the 
problem  boils  down  to  the  desire  for  an  unannotated  let-module  construct.  Suppose  that  we  had 
such  a  construct,  written  let  X  =  Mi  in  M2,  with  exactly  the  same  typing  rule  as  annotated  let’s 
(Rule  101).  Then  clearly  the  above  derived  forms,  minus  the  signature  annotations,  would  give  us 
a  way  of  encoding  second  projections  and  functor  applications  in  which  the  constituent  module  M 
need  not  be  projectible. 

The  difficulty  comes  in  computing  the  principal  signature  of  let  X  =  Mi  in  M2.  Say  that  the 
principal  signature  of  Mj  is  S^.  The  signature  S2  may  refer  to  the  variable  X.  To  construct  a 
principal  signature  for  the  let,  we  need  to  find  a  minimal  supersignature  of  S2  that  avoids  reference 
to  X.  The  “avoidance  problem”  [22,  45]  is  that  such  a  minimal  supersignature  does  not  always 
exist.  The  same  problem  arises  at  the  level  of  constructors  and  kinds  as  well;  given  a  kind  K  that 
refers  to  a  constructor  variable  a,  there  is  not  necessarily  any  minimal  superkind  of  K  that  avoids 
a.  For  example,  consider  the  kind  K  =  (T  ^S(a))  x  5(a),  which  refers  to  a  variable  a  bound  with 
kind  T.  One  obvious  super  kind  of  K  that  avoids  a  is  (T  ^  T)  x  T,  but  there  are  more  precise  ones. 
Specifically,  for  any  type  C  of  kind  T  that  does  not  mention  a,  the  kind  S/3:(T  ^  T).S(/3(C))  is  an 
a-avoiding  superkind  of  K.  For  different  choices  of  C,  however,  the  superkinds  are  incomparable, 
and  there  is  no  minimal  one. 

Going  back  to  the  original  problem  of  allowing  second  projections  and  functor  applications 
involving  non-projectible  modules,  there  is  an  alternative  solution  employed  by  Harper  and  Lil- 
libridge  [28]  in  their  module  type  system.  The  idea  is  to  allow  7r2M  and  F'”(M),  even  when  M  is 
not  projectible,  so  long  as  in  the  first  case  M  can  be  given  a  non-dependent  pair  signature  Si  x  S2, 
and  in  the  second  case  F  can  be  given  a  non-dependent  functor  signature  Si  — >  S2.  In  both  cases, 
the  signature  of  the  result  is  merely  S2,  avoiding  any  need  to  substitute  a  non-projectible  module 
for  a  variable.  Nevertheless,  Harper  and  Lillibridge’s  type  system  still  runs  afoul  of  the  avoidance 
problem.  For  instance,  take  the  7r2M  case.  The  principal  signature  of  M  may  be  a  dependent  pair 
signature  S  =  SX:Si.S2.  Computing  the  principal  signature  of  7r2M  will  thus  require  finding  a  min¬ 
imal  non-dependent  supersignature  of  S.  This  is  tantamount  to  finding  a  minimal  supersignature 
of  S2  that  avoids  mentioning  X*^,  which  is  precisely  the  avoidance  problem. 

Different  dialects  of  ML  handle  the  avoidance  problem — or  do  not  handle  it — in  different  ways. 
The  type  system  of  this  chapter  sidesteps  the  avoidance  problem  by  requiring  signature  annotations 
on  let-modules  and  restricting  arguments  to  functors  and  second  projections  to  be  projectible. 
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#  module  type  S  =  sig  type  t  end 
module  F  =  functor  (X  :  S)  -> 

struct  type  u  =  X.t  type  v  =  X.t  end 
module  G  =  functor  (X  :  S)  -> 

struct  type  u  =  X.t  type  v  =  u  end 
module  AppF  =  F( (struct  type  t  =  int  end  :  S)) 

module  AppG  =  G( (struct  type  t  =  int  end  :  S));; 

(*  Output  of  the  Objective  Caml  3.07+2  compiler  *) 
module  type  S  =  sig  type  t  end 
module  F  :  functor  (X  :  S)  -> 

sig  type  u  =  X.t  and  v  =  X.t  end 
module  G  :  functor  (X  :  S)  -> 
sig  type  u  =  X.t  and  v  =  u  end 
module  AppF  :  sig  type  u  and  v  end 

module  AppG  :  sig  type  u  and  v  =  u  end 

Figure  4.12;  Encoding  of  the  Avoidance  Problem  in  O’Caml 


Shao’s  type  system  makes  similar  restrictions,  and  these  enable  his  language  to  support  principal 
signatures  [69]. 

On  the  other  hand,  both  the  Harper-Lillibridge  “translucent  sums”  calculus  [28]  and  Leroy’s 
“manifest  types”  calculus  [42]  do  not  attempt  to  work  around  the  avoidance  problem  at  all,  and  thus 
lack  principal  signatures.  Objective  Caml,  based  on  Leroy’s  work,  also  lacks  principal  signatures. 
Most  of  the  time  this  does  not  cause  serious  problems,  but  on  occasion  it  leads  to  unpredictable 
typechecking,  as  illustrated  in  the  O’Caml  code  shown  in  Figure  4.12.  Two  functors  F  and  G  are 
defined  that  have  equivalent,  transparent  principal  signatures.  Yet  when  the  functors  are  applied 
to  the  same  sealed  module  expression,  the  signatures  of  the  results  AppF  and  AppG  differ  rather 
arbitrarily,  based  on  some  purely  syntactic  discrepancy  between  the  signatures  of  F  and  G. 

The  semantics  of  Standard  ML,  as  described  by  Harper  and  Stone  [32],  addresses  the  avoidance 
problem  differently,  and  in  such  a  way  that  avoids  the  unpredictability  of  O’Caml  typechecking. 
SML  interprets  the  unannotated  let  X  =  Mi  in  M2  as  if  it  were  the  pair  module  (X  =  Mi,M2), 
and  then  ensures  via  elaboration  techniques  that  the  second  component  of  this  pair  is  the  only 
one  visible  from  outside  the  let.  Applications  of  functors  to  non-projectible  modules  are  handled 
by  first  rewriting  them  in  terms  of  let-expressions  (via  the  encoding  given  earlier  in  this  section) 
and  then  interpreting  the  let’s  as  pairs.  (Second  projections  may  be  rewritten  similarly,  but  SML 
chooses  to  only  permit  projections  from  paths.) 

Do  modules  in  SML  have  principal  signatures?  Yes  and  no.  Under  the  Harper-Stone  interpreta¬ 
tion  of  SML,  SML  modules  are  translated  to  internal-language  (IL)  modules,  and  these  IL  modules 
do  have  principal  signatures  in  the  IL.  However,  the  principal  IL  signature  of  an  IL  module  does  not 
necessarily  correspond  to  any  SML  signature,  so  one  cannot  always  write  the  principal  signature 
of  an  SML  module  in  SML  itself.  (As  Shao  would  say,  SML  lacks  “fully  syntactic”  signatures.) 
Returning  to  the  example  in  Figure  4.12,  if  we  were  to  write  this  code  in  SML,  then  AppF  would 
receive  the  IL  signature  sig  type  u  =  ?.t  and  v  =  ?.t  end,  where  ?.t  stands  for  the  abstract 
t  component  of  the  unnamed  argument  module.  There  is  no  way  to  write  this  signature  in  SML 
itself,  but  at  least  we  can  count  on  the  fact  that  AppF.u  =  AppF.v,  which  is  not  true  in  O’Caml. 
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There  is  a  simple,  reasonable  tradeoff  here:  SML  modules  written  without  the  use  of  unanno¬ 
tated  let’s  (and  the  other  features  encoded  in  terms  of  them)  will  have  principal  signatures  in  SML, 
whereas  modules  that  employ  the  more  flexible  let  construct  may  not.  The  language  I  define  in 
Part  III  follows  the  SML/Harper-Stone  approach  to  dealing  with  the  avoidance  problem. 

4.2.7  Module  Phase-Splitting 

In  this  final  section,  I  define  a  phase-splitting  translation  for  modules  to  match  the  one  for  signatures 
given  in  Section  4.1.4.  The  module  translation  explains  how  modules  may  be  interpreted  in  terms 
of  core-language  constructs,  avoiding  the  need  to  give  a  separate  dynamic  semantics  and  type 
safety  proof  for  the  module  language  itself.  The  translation  does  not,  however,  preserve  all  the 
data  abstraction  guarantees  of  the  module  language.  In  particular,  it  ignores  basic  sealing,  in 
the  sense  that  if  M  is  a  pure  module  then  M  and  M  :>p  S  phase-split  to  the  same  result.  I  also 
define  translations  for  terms  and  dynamic  contexts  that  interpret  the  new  term-level  constructs 
and  context  binding  forms  introduced  in  this  chapter  in  terms  of  existing  core-language  constructs. 

The  translations  for  modules,  terms  and  contexts  are  shown  in  Figures  4.13  and  4.14.  All  of 
these  translations  produce  syntactic  objects  that  are  well- formed  in  the  type  system  of  the  core 
language  of  Chapter  3.  I  will  refer  to  such  syntactic  objects  as  “core”  objects. 

The  translation  of  dynamic  contexts  has  the  form  T  ^  T',  mapping  a  module- language  dynamic 
context  T  to  a  core  context  For  any  core  bindings  of  constructor  variables  a  or  value  variables 
X,  the  translation  is  the  identity.  For  a  module  variable  binding  X:S,  the  translation  splits  X  into 
a  constructor  variable  X*^  (representing  the  static  part  of  X)  and  a  value  variable  X'^  (representing 
the  dynamic  part  of  X).^^  The  kind  and  type  with  which  X*^  and  X""  are  bound,  respectively,  are 
determined  by  phase-splitting  X’s  signature  S. 

The  translation  of  modules  involves  two  judgments,  one  for  pure  modules  and  one  for  impure 
modules.  These  judgments  are  patterned  on  the  signature  synthesis  algorithm  of  Figure  4.11,  in 
the  sense  that  the  derivation  of  the  translation  of  M,  be  it  pure  or  impure,  matches  precisely  the 
structure  of  the  signature  synthesis  derivation  for  M.  The  difference  between  the  pure  and  impure 
translation  judgments  is  in  their  output.  The  pure  judgment,  written  FI-M^pS^[C,e],  splits 
M  into  a  constructor  C  (representing  the  static  part  of  M)  and  a  term  e  (representing  the  dynamic 
part  of  M).  It  is  modeled  closely  on  the  non-standard  module  equivalence  rules  set  forth  by  Harper, 
Mitchell  and  Moggi  [30]  in  their  phase-distinction  calculus.  Impure  modules,  on  the  other  hand, 
have  the  property  that  they  cannot  necessarily  be  phase-split  in  this  way — the  identities  of  their 
type  components  may  not  be  knowable  until  run  time.  Therefore,  the  impure  translation  judgment 
has  the  form  FI-M=^iS^e,  where  e  is  a  core  term  with  package  type  This  judgment 

does  not  really  “split”  M,  it  packages  M  as  a  term,  so  I  call  it  an  “impure  packaging”  judgment. 

In  a  number  of  the  translation  rules — especially  those  for  modules,  like  pairs,  whose  submodules 
may  or  may  not  be  pure — it  is  very  convenient  to  be  able  to  implicitly  coerce  the  result  of  pure 
module  phase-splitting,  which  has  the  form  [C,e],  into  the  result  of  impure  module  packaging, 
which  is  just  a  term.  This  coercion  is  implemented  by  the  judgment  F  h  M  =^p  S  ^  e,  shown 
at  the  bottom  of  Figure  4.13.  It  merely  takes  the  result  [C,e]  of  phase-splitting  M  and  pack’s  it 
with  type  (jS^.  This  “pure  packaging”  judgment,  together  with  the  impure  packaging  judgment, 
defines  a  single  packaging  judgment  of  the  form  FFM^^S^e.  This  packaging  judgment  has 
the  property  that  the  output  term  e  has  package  type  (|SD,  where  S  is  the  principal  signature  of  M. 

^°The  use  of  and  X''  is  due  to  Harper,  Mitchell  and  Moggi  [30] — the  “c”  in  X'^  stands  for  “compile-time,”  and 
the  “r”  in  X'^  stands  for  “run-time.” 

^^Note  that  this  package  type  (jS^  is  really  a  core  type  because  (jS^  is  just  a  macro — the  module  language  of  this 
chapter  has  not  extended  the  core  language  of  types  in  any  way. 
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r  ^  r'  r  r'  r  ^  r'  s  ^  Ix^:K.c] 

0^0  r,a:K^r',a:K  r,x:C^r',x:C  T,  X:S  ^  T',  X^:K,  X^:C 


Pure  module  phase-splitting:  F  h  M  =^p  S  [C,e] 

_ X:S  e  r _  _ 

r  h  X  ss(x)  ^  [x^x^  r  h  0  ^p  1  ^  [(),  ()] 

r  h  c  ^  K  rhe^c 

r  h  [C]  ^p  IKI  ^  [C,  ()]  r  h  [e]  ^p  [Cl  ^  [(),  e] 

r  h  Ml  ^p  Si  ^  [Cl,  ei]  r,  X:Si  h  Ms  ^p  Ss  ^  [Cs,  es] 
r  h  (X  =  Mi,M2)  ^p  SXiSi.Ss  =1  [(X^  =  Ci,C2),  let  X"  =  Cl  in  let  X^  =  ei  in  (X^e2)] 
r  h  M  ^P  SXiSi.Ss  [C,  e]  r  h  M  ^p  SXiSi.Sa  ^  [C,  e] 

r  h  ttiM  =^p  Si  ^  [vTiCjTTie]  F  h  ttsM  =^p  S2[vriM/X]  ^  [vrsCjTTse] 

F  h  Si  ^  [XFKi.Cil  F, X:Si  h  M  ^p  S2  ^  [C,  e] 

F  h  At°tX:Si.M  ^p  nt°tX:Si.S2  ^  [AXFKp.C,  AXFKi.AXFCi.e] 

FhF^pnt°tX:Si.S2^[Ci,ei]  F  h  M  ^p  S  [C2,  ea]  F  h  S  <  Si 
F  h  Ft°t(M)  ^p  S2[M/X]  ^  [Ci(C2),  ei[C2](e2)] 

F  h  Si  ^  iXFKi.Cil  F, X:Si  h  M  S  ^  e  F,  X;Si  h  S  <  S2 
F  h  AP"^(X:Si):S2.M  ^p  PP'^XiSi-Ss  ^  [(),  AXFKi.AXFCi. coerce  e  to  ^Ss^] 

F  h  M  ^P  S'  =1  [C,  e]  F  h  S'  <  S 
F  h  M  :>p  S  ^p  S  [C,e] 

F  h  M  S  e  S  [a;]K.C] 

F  h  purify(M)  =>p  S  [Can(]K),  let  [a,x\  =  unpack  e  in  (x  :  C[Can(]K)/a])] 

FhMi  ^pSi  ^  [Ci,ei]  F,X:Si  FMs  ^P  S2  ^  [C2,e2]  F,X:SihS2<S  F  h  S  sig 


F  h  let  X  =  Mi  in  (Ms  ;  S)  =^p  S  ^  [let  X'^  =  Ci  in  C2,  let  X*^  =  Ci  in  let  X''  =  ei  in  ea] 

Pure  module  packaging:  F  h  M  =^p  S  ^  e 


F  h  M  ^P  S  ^  [C,  e] 

F  h  M  =^p  S  pack  [C,e]  as  (jS^ 


Figure  4.13;  Module,  Term  and  Context  Translation 
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Impure  module  packagiug:  ThM^i  S^e 

r  h  Ml  Si  ei  r,Xi:Si  h  M2  S2  62  KiU  K2  =  1 
r  h  (Xi  =Mi,M2)  5]Xi:Si.S2 

let  [X^jX^]  =  unpack  ei  in  let  [X^jX^]  =  unpack  62  in  pack  [(X^, X2),  (X^,  X2)]  as  {|SXi;Si.S2^ 

_ r  h  M  XX:Si.S2  ^  6 _ 

r  h  ttiM  =^i  Si  let  [a,x\  =  unpack  e  in  pack  [7riQ;,7rix]  as  (|Si^ 

_ r  h  F  n^°^X:Si.S2  6  r  h  M  s  [c, 6^]  r  h  s  <  Si _ 

r  h  F'^°'^(M)  S2[M/X]  let  [a,x\  =  unpack  e  in  pack  [a(C), x[C](e')]  as  (|S2[M/X]^ 

F  h  F  nP^^X:Si.S2  ^6  F  h  M  S  ^  [C,  e']  F  h  S  <  Si 
F  h  FP"^(M)  S2[M/X]  ^  let  [_,x]  =  unpack  e  in  (x[C](e')  :  ^S2[M/X]^) 

F  h  M  s' ^6  FI-S'<S  kUk'  =  I 
F  h  (M  :>K  S)  S  ^  coerce  e  to  (|SD 

F  h  S  sig  F  h  6  ^  C  e'  F  h  C  =  ^S^  T 
F  h  unpack  e  as  S  S  e' 

F  h  Ml  Si  ^  61  F,  X:Si  h  M2  S2  ^  62 
r,X:SihS2<S  FhSsig  ki  U  ^2  =  I 
F  h  let  X  =  Mi  in  (M2  :  S)  S  ^  let  [X'^,X'']  =  unpack  61  in  coerce  62  to  (|SD 

Term  trauslatiou:  F  h  6  C  ^  c' 

_ F  h  M  ^  6 _ 

F  h  Term(M)  ^  C  let  ,  x]  =  unpack  e  in  (x  ;  C) 

rhM^^S'^6  FhS'<S 
F  h  pack  M  as  S  ^  {|S^  coerce  e  to  {|S^ 

All  other  term  phase-splitting  rules  are  defined  in  the  obvious  inductive  manner,  e.g., 

F  h  ui  ^  Cl  u'l  F  h  U2  C2  ^  ^2 

F  h  (ui,U2)  ^  Cl  X  C2 

Figure  4.14;  Module,  Term  and  Context  Translation  (continued) 
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The  term  translation  judgment  has  the  form  T  h  e  C  ^  e',  where  e'  is  guaranteed  to  be  core 
and  still  have  e’s  type  C.  For  all  the  core  term  constructs,  this  term  translation  simply  recurses  on 
the  subterms.  The  translation  only  does  something  for  the  term  constructs  involving  modules. 

Both  the  term  and  module  translation  judgments  make  frequent  use  of  the  following  syntactic 
sugar  for  coercing  from  one  package  type  to  another; 

coerce  e  to  (|SD  let  [a,x\  =  unpack  e  in  pack  [a,x\  as  (|S^ 

It  is  easy  to  check  that  the  term  coerce  e  to  (IS^  is  well- formed  (with  type  (IS^l  whenever  e  has  type 
and  S'  is  a  subtype  of  S. 

As  for  the  rules  themselves:  I  have  already  described  how  most  of  the  pure  module  phase- 
splitting  rules  work  in  my  discussion  of  signature  phase-splitting  in  Section  4.1.4.  The  only  one 
that  requires  special  comment  here  is  the  rule  for  purify(M).  In  this  case,  the  module  M  may  be 
impure,  so  the  premise  requires  only  that  M  translate  to  the  package  e.  Ordinarily  this  does  not  give 
us  a  way  of  phase-splitting  M.  However,  since  M’s  signature  S  is  transparent,  we  know  that  there 
is  a  canonical  constructor^^  Can(Fst(S))  of  kind  Fst(S),  which  can  be  used  to  represent  the  static 
part  of  M.  Then,  to  obtain  M’s  dynamic  part,  we  simply  unpack  e  into  a  and  x,  and  then  export 
X.  There  is  no  problem  with  the  constructor  variable  a  escaping  its  scope  because  Can(Fst(S))  is 
equivalent  to  a  and  can  thus  be  substituted  for  a  in  the  type  of  x. 

The  packaging  rules  for  impure  modules  are  not  fundamentally  that  different  from  the  phase- 
splitting  rules  for  pure  modules.  The  rule  for  pair  modules,  for  instance,  pairs  the  static  parts  of  the 
two  submodules  into  one  constructor  and  pairs  their  dynamic  parts  into  one  term.  The  difference 
is  that  the  static  parts  of  the  submodules  are  not  statically  known.  All  we  have  for  each  submodule 
Mj  is  its  translation  as  the  package  e*.  We  must  therefore  first  unpack  each  e*  into  X?  and 
before  we  can  pair  the  static  parts  together  and  the  dynamic  parts  together.  In  the  end,  the  result 
must  be  packaged  up  again  as  a  term.  Nearly  all  the  packaging  rules  follow  this  same  procedure: 
unpack,  then  phase-split,  then  pack. 

Finally,  here  is  a  proposition  summarizing  soundness  and  related  properties  of  the  translations 
defined  in  this  section.  The  proof  goes  through  by  straightforward  induction. 

Proposition  4.2.7  (Properties  of  Module,  Term  and  Context  Translation) 

Assume  F  h  ok.  Then,  F  ^  F'  and: 

1.  F'  F  ok  and  F'  is  core. 

2.  Fst(F)  =  Fst(F').  Thus,  for  all  static  judgments  J  .,T  \-  J  \i  and  only  if  F'  h  J . 

3.  F  h  e  C  if  and  only  if  there  exists  a  core  e'  such  that  F  h  e  C  ^  e'. 

4.  If  F  h  e  ^  C  ^  e',  then  F'  F  e'  :  C.  Also,  if  e  is  a  value,  then  e'  is  a  value. 

5.  F  F  M  S  if  and  only  if  there  exists  a  core  e  such  that  F  F  M  S  e. 

6.  If  F  F  M  S  ^  e,  then  F'  F  e  :  {|S). 

7.  F  F  M  =^p  S  if  and  only  if  there  exist  core  C  and  e  such  that  F  F  M  =^p  S  ^  [C,  e]. 

8.  If  F  F  M  =^p  S  =1  [C,  e]  and  S  ^  |a:K.D],  then  F'  F  C  :  K  and  F'  F  e  :  D[C/a]. 

9.  If  F  F  M  ^P  S  ^  [C,  e],  then  C  =  Fst(M). 

Proof:  By  straightforward  induction  on  the  translation.  ■ 


^■^Canonical  constructors  Can(]K)  were  defined  in  Section  3.1.1. 
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The  Recursive  Module  Problem 


Recursive  modules  are  one  of  the  most  frequently  requested  extensions  to  the  ML  languages.  After 
all,  the  ability  to  have  cyclic  dependencies  between  pieces  of  code  written  in  separate  files  is  a 
feature  that  is  commonplace  in  mainstream  languages  like  C  and  Java,  languages  which  are  not 
nearly  as  expressive  as  ML  in  other  ways.  From  the  programmer’s  perspective,  it  seems  very  strange 
that  the  ML  module  system  should  provide  such  powerful  mechanisms  for  data  abstraction  and 
code  reuse,  and  yet  not  provide  any  support  for  recursive  modules.  Certainly,  for  simple  examples 
of  recursive  modules,  it  is  difficult  to  convincingly  argue  why  ML  could  not  be  extended  to  allow 
them.  However,  when  one  considers  the  semantics  of  a  general  recursive  module  mechanism,  one 
runs  into  a  host  of  interesting  problems  for  which  the  “right”  solutions  are  far  from  obvious. 

In  this  chapter,  I  explore  at  a  high  level  the  problem  of  extending  ML  with  recursive  modules.  I 
begin  in  Section  5.1  by  giving  several  examples  of  how  recursive  modules  would  constitute  a  useful 
extension  to  ML.  In  Section  5.2,  I  lay  out  the  key  concepts  and  issues  that  arise  in  the  design  of  a 
recursive  module  extension.  Many  of  the  ideas  in  this  section  are  based  on  previous  work  by  Crary, 
Harper  and  Puri  [6],  but  there  are  a  number  of  new  observations  as  well.  In  Section  5.3,  I  examine 
a  number  of  existing  recursive  module  proposals,  and  weigh  their  advantages  and  disadvantages. 
Finally,  in  Section  5.4,  I  describe  my  own  proposal  for  a  recursive  module  extension  to  ML,  which 
I  will  formalize  fully  in  Part  HI. 

While  much  of  my  proposed  semantics  for  recursive  modules  relies  on  elaboration  techniques, 
it  also  involves  some  extensions  to  my  type  system  for  modules  from  Chapters  3  and  4.  These 
extensions  are  presented  in  Chapter  6.  In  addition,  there  is  one  aspect  of  recursive  modules — 
namely,  the  static  detection  of  “unsafe”  (or  “ill-founded” )  recursive  definitions — that  I  discuss  only 
briefly  in  the  present  chapter.  This  topic  is  examined  more  thoroughly  in  Chapter  7. 


5.1  Motivating  Examples 

There  are  several  reasons  why  recursive  modules  would  be  useful  to  have  in  ML.  The  primary  one 
is  to  enhance  the  language’s  support  for  data  abstraction.  One  of  the  main  methodological  goals 
of  modules  is  to  help  the  programmer  weaken  the  dependencies  between  program  components  by 
breaking  them  into  separate  modules.  However,  if  f  and  g  are  mutually  recursive  functions,  then  the 
ML  programmer  is  forced  to  write  their  definitions  together  in  the  same  module.  This  restriction  is 
unfortunate  because  it  means  that  there  is  no  way  to  hide  information  about  the  implementation 
of  f  from  the  implementation  of  g  or  vice  versa — they  are  typechecked  in  the  same  typing  context. 
Similarly,  if  t  and  u  are  mutually  recursive  datatype’s,  then  the  ML  programmer  is  forced  to  define 
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structure  rec  Expr  :>  sig  type  t  ;  val  eval  :  t  ->  t  ;  ...  end  = 
struct 

datatype  t  =  VarExpr  of  var  |  LetExpr  of  Bind.t  *  t  |  ... 
fun  eval  (e  :  t)  :  t  = 
case  e  of  ... 

I  LetExpr  (b,e)  =>  ...  Bind. eval (b)  . . . 

end 

and  Bind  :>  sig  type  t  ;  val  eval  :  t  ->  (var  *  Expr.t)  list  ;  ...  end  = 
struct 

datatype  t  =  . . .  |  ValBind  of  var  *  Expr.t  |  ... 
fun  eval  (b  :  t)  :  (var  *  Expr.t)  list  = 
case  b  of  ... 

I  ValBind  (v,e)  =>  [ (v, Expr. eval (e))] 


end 


Figure  5.1;  Mutually  Recursive  Modules  Expr  and  Bind 


them  together  as  well.  Forcing  program  components  to  be  written  together,  regardless  of  whether 
they  belong  together  conceptually,  contradicts  the  ideals  of  data  abstraction  and  code  reuse. 

Figure  5.1  shows  a  canonical  example  of  where  it  might  be  desirable  to  break  mutually  recursive 
types  and  functions  into  separate  modules.  There  are  two  modules,  Expr  and  Bind.  Each  module 
provides  a  type  t  representing  a  different  syntactic  class — “expressions”  in  one  case,  “bindings”  in 
the  other — in  the  abstract  syntax  of  some  language,  along  with  an  eval  function  that  implements 
the  dynamic  semantics  of  that  language.  For  Expr,  the  eval  function  evaluates  an  expression 
(represented  by  its  argument)  to  a  value,  and  returns  the  piece  of  abstract  syntax  (of  type  Expr.t) 
corresponding  to  that  value.  For  Bind,  the  eval  function  evaluates  the  binding(s)  represented  by 
its  argument,  and  returns  a  list  of  variable- value  pairs. 

Note  that  the  types  Expr .  t  and  Bind .  t  have  mutually  recursive  definitions,  as  do  the  functions 
Expr .  eval  and  Bind .  eval.  One  of  the  benefits  of  breaking  these  types  and  functions  into  separate 
modules  is  that  the  implementation  of  Expr  cannot  rely  on  how  Bind.t  is  defined,  nor  can  Bind 
rely  on  how  Expr .  t  is  defined,  because  each  module  is  sealed  with  an  opaque  interface  that  hides 
the  definition  of  its  t  component.  This  ensures  that  the  implementation  of  each  module  will  remain 
well-typed  under  changes  to  the  other  module,  so  long  as  those  changes  do  not  affect  its  interface. 
Admittedly,  for  this  example  to  make  any  sense,  we  do  need  to  provide  some  extra  functionality 
in  these  interfaces  so  that  one  may  actually  create  a  value  of  type  Expr.t  or  Bind.t,  but  doing  so 
does  not  require  us  to  reveal  the  definitions  of  those  types. 

There  are  at  least  two  common  techniques  that  programmers  use  in  practice  to  work  around 
ML’s  restrictions  and  make  up  for  the  lack  of  a  structure  rec  construct.  Let’s  say  we  are  trying 
to  break  up  functions  f  and  g  into  separate  modules  A  and  B.  One  technique,  shown  in  Figure  5.2, 
is  to  first  define  a  preliminary  module  PreA  that  defines  f  as  parameterized  over  a  definition  for  g 
since  g  has  not  been  defined  yet.  The  module  B  can  then  define  g,  with  references  to  “f  ”  replaced 
by  PreA.f  (g).  Finally,  we  can  write  the  real  module  A,  which  “ties  the  recursive  knot”  by  defining 
the  real  f  as  the  instantiation  of  the  preliminary  PreA.f  with  the  real  B.g.  One  can  similarly 
break  up  mutually  recursive  datatype  definitions  by  parameterizing  one  type  over  the  other  and 
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structure  PreA  =  struct 
fun  fgx=  ...  g(...)  ... 
end 

structure  B  =  struct 

fun  g  y  =  let  val  f  =  PreA .f  g  in  ...  f(...)  ... 
end 

structure  A  =  struct 
val  f  =  PreA.f  B.g 
end 

Figure  5.2;  Parameterization  Workaround  for  Separating  Recursive  Function  Definitions 


structure  A  =  struct 
local 

val  ref_g  :  (Ci  ->  C2)  ref  =  ref  (fn  _  =>  raise  Error) 
fun  g  X  =  (!ref_g)  x 
in 

fun  install_g  real_g  =  (ref_g  :=  real_g) 

fun  fx=  ...  g(...)  ... 

end 

end 

structure  B  =  ...  (*  defines  g  directly  in  terms  of  A.f  *)  ... 
val  _  =  A.install_g  B.g 

Figure  5.3;  Backpatching  Workaround  for  Separating  Recursive  Function  Definitions 


instantiating  it  later  on.  This  parameterization  technique  is  rather  awkward,  though,  as  it  requires 
the  definition  of  a  whole  extra  module  (PreA). 

Figure  5.3  illustrates  an  alternative  workaround,  which  is  similar  to  Scheme’s  “backpatching” 
semantics  for  recursive  definitions  [38].  The  idea  is  to  define  in  module  A  a  reference  cell  ref  _g 
containing  a  dummy  function,  which  will  eventually  be  updated  (backpatched)  with  the  real  B .  g. 
Uses  of  g  inside  the  body  of  A .  f  will  first  dereference  ref  _g  to  obtain  the  real  g  and  then  apply  the 
result.  The  module  B  can  then  define  g  directly  in  terms  of  A.f.  Once  B  is  defined,  A’s  ref  _g  can 
be  backpatched  via  the  install_g  function  that  A  provides.  Despite  its  use  of  mutable  state,  this 
approach  is  somewhat  cleaner  than  the  parameterization  workaround  because  it  does  not  require 
one  to  define  two  versions  of  the  module  A.  In  addition,  it  localizes  the  dirty  work  to  module  A; 
module  B  is  written  as  if  its  reference  to  A .  f  were  strictly  hierarchical.  On  the  other  hand,  it  is 
limited  in  that  it  does  not  help  in  separating  mutually  recursive  datatype’s. 

The  above  techniques  are  essentially  stopgap  solutions — they  work  acceptably  on  a  small  scale, 
but  are  no  substitute  for  a  real  recursive  module  mechanism.  Moreover,  there  are  examples  that 
are  only  expressible  in  the  presence  of  recursive  modules.  The  best-known  such  example  is  an 
implementation  of  “bootstrapped  heaps”  from  Okasaki’s  thesis  [59].  A  stripped-down  version  of 
this  example  (adapted  from  Russo  [66])  is  shown  in  Figure  5.4. 

The  Bootstrap  functor  takes  as  input  a  functor  MkHeap  providing  an  implementation  of  heaps, 
and  a  module  Ord  providing  some  type  of  ordered  elements.  It  returns  a  module  implementing  heaps 
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signature  ORDERED  =  sig  type  t  ;  val  leq  :  t  *  t  ->  bool  end 
signature  HEAP  =  sig 

structure  Elem  :  ORDERED 
type  t 

val  empty  :  t 

val  insert  :  Elem.t  *  t  ->  t 
val  merge  :  t  *  t  ->  t 
val  findMin  :  t  ->  Elem.t  option 
end 

functor  Bootstrap  (functor  MkHeap  :  (X  :  ORDERED)  -> 

HEAP  where  type  Elem.t  =  X.t 
structure  Ord  :  ORDERED) 

:>  HEAP  where  type  Elem.t  =  Ord.t  = 

struct 

structure  Elem  =  Ord 
structure  rec  Boot  :> 
sig 

datatype  t  =  E  |  H  of  Elem.t  *  Heap.t 
val  leq  :  t  *  t  ->  bool 
end  = 
struct 

datatype  t  =  E  |  H  of  Elem.t  *  Heap.t 
fun  leq  (H(x,_),  H(y,_))  =  Elem. leq(x,y) 
end 

and  Heap  :>  HEAP  where  type  Elem.t  =  Boot.t  = 

MkHeap (Boot) 

open  Boot  (*  type  t  =  Boot.t  *) 

val  empty  =  E 
fun  merge  (E,h)  =  h 
I  merge  (h,E)  =  h 

I  merge  (hi  as  H(x,pl),  h2  as  H(y,p2))  = 
if  Elem. leq(x,y)  then  H(x,Heap. insert(h2,pl) 
else  H(y .Heap . insert (hi ,p2) 
fun  insert  (x,h)  =  merge  (H (x, Heap . empty) ,h) 
fun  findMin  E  =  NONE 

I  findMin  (H(x,_))  =  SOME  x 

end 


Figure  5.4:  Bootstrapped  Heap  Example 
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datatype  ’at=A  |  Bof  ’a*  'att 


structure  rec  X  :>  sig  val  collect 
struct 

fun  collect  (A)  =  [] 

I  collect  (B(x,TT))  =  (* 

let  val  XL  =  X. collect  XT  (* 
val  LL  =  map  collect  XL  (* 
val  L  =  flatten  LL  (* 

in  x: :L  end 


’at  ->  ’a  list  end  = 


x:C,  XX:C*Ctt*) 

X. collect  :  C  t  t  ->  C  t  list  *) 
collect  :  C  t  ->  C  list  *) 
flatten  :  C  list  list  ->  C  list  *) 


end 


Figure  5.5:  Encoding  Polymorphic  Recursion  Using  a  Recursive  Module 


of  Ord.t’s,  for  which  the  merge  and  findMin  operations  are  constant-time,  assuming  that  those 
operations  were  O(logn)  and  that  insert  was  constant-time  in  MkHeap’s  original  implementation. 

A  “bootstrapped”  heap,  i.e.,  a  value  of  this  new  heap  type,  is  either  the  empty  heap,  E,  or 
a  node  H(x,h),  where  x  is  the  minimum  element  in  the  heap,  and  h  is  a  heap  (implemented  by 
MkHeap)  containing  the  rest  of  the  elements.  However,  this  internal  heap  h  is  not  a  heap  of  Drd.t’s, 
it  is  a  heap  of  bootstrapped  heaps!  In  other  words,  the  type  of  bootstrapped  heaps  is  defined  in 
terms  of  heaps  of  itself.  There  is  no  way  to  define  such  a  type  in  existing  dialects  of  ML,  because 
there  is  no  way  to  write  a  datatype  definition  that  is  recursive  with  a  functor  application.  This  is 
completely  straightforward,  though,  in  the  presence  of  recursive  modules. 

It  is  worth  noting  that,  in  the  type  system  for  modules  I  presented  in  Chapters  3  and  4,  the 
bootstrapped  heap  example  can  be  encoded  without  the  use  of  module-level  recursion,  thanks  to 
the  concept  of  phase  separation.  Assuming  that  MkHeap  is  a  total/applicative  functor,  the  type 
Boot .  t  could  be  defined  recursively  as  follows: 

datatype  t  =  E  |  H  of  Elem.t  *  MkHeap '^(t)  .t 

Recall  that  MkHeap'^  is  the  type  constructor  representing  the  static  part  of  the  MkHeap  functor.  It 
only  takes  the  type  of  elements  as  its  argument,  not  the  comparison  function,  and  the  t  component  it 
returns  describes  heaps  of  those  elements.  By  employing  this  definition  for  the  type  of  bootstrapped 
heaps,  we  can  break  the  dependency  of  the  Boot  structure  on  the  Heap  structure.  Nevertheless, 
one  can  easily  imagine  a  modified  version  of  this  example  in  which  the  dynamic  part  of  Boot  (i.e., 
Boot .  leq)  referred  recursively  to  the  Heap  structure  as  well.  In  that  case,  phase  separation  would 
not  suffice  to  break  the  cyclic  dependency. 

Another  example  of  how  recursive  modules  fundamentally  increase  the  language’s  expressive¬ 
ness  is  that  they  enable  polymorphic  recursion,  i.e.,  the  ability  to  write  recursive  polymorphic 
functions  that  instantiate  their  type  arguments  differently  at  different  recursive  calls.  While  ML 
allows  polymorphic  datatype’s  to  be  “non-uniform” — meaning  that  their  definitions  may  contain 
instantiations  of  themselves  at  different  types — there  is  no  way  to  write  functions  that  recur  over 
non-uniform  datatypes  because  ML  does  not  support  polymorphic  recursion.  (Type  inference  is 
undecidable  in  the  presence  of  full  polymorphic  recursion  [34,  39].) 

With  recursive  modules,  however,  polymorphic  recursion  comes  for  free.  Figure  5.5  shows  an 
illustrative,  if  somewhat  contrived,  example  of  a  type  ’a  t  whose  definition  is  similar  to  that  of 
’a  list,  except  that  the  tail  of  an  ’a  t  has  type  ’a  t  t  instead  of  ’a  t.  The  recursive  structure 
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X  defines  a  function  collect  that  collects  all  the  values  of  type  'a  stored  within  an  ’a  t  and 
forms  an  'a  list  of  them.  Within  the  definition  of  collect,  the  type  variable  ’a  is  fixed  to 
some  particular  unknown  type — call  it  C — and  the  variable  collect  has  the  monomorphic  type 
C  t  ->  C  list.  Yet,  in  the  intermediate  step  defining  the  variable  XL,  we  need  collect  to  have 
type  C  t  t  ->  C  t  list.  Instead  we  can  make  use  of  X. collect,  which  has  the  polymorphic 
type  V  ’a.  'at  ->  'a  list.  By  implicitly  instantiating  the  type  argument  of  X.  collect  with 
C  t,  we  obtain  a  value  of  the  desired  type. 

What  the  recursive  module  is  essentially  doing  for  us  in  this  example  is  giving  us  a  place  to 
write  down  the  type  of  X.  collect.  Polymorphic  recursion  could  just  as  easily  be  added  directly  to 
the  core  ML  language,  if  polymorphically  recursive  functions  were  required  to  be  annotated  with 
their  types.  Nonetheless,  recursive  modules  seem  to  be  useful  in  a  number  of  situations,  and  they 
provide  an  elegant  way  of  encoding  various  paradigms  that  are  either  awkward  or  impossible  to 
implement  in  existing  dialects  of  ML. 

5.2  Key  Issues  in  the  Design  of  a  Recursive  Module  Extension 

In  the  motivating  examples  of  the  previous  section,  I  made  use  of  a  make-believe  “structure  rec” 
binding  of  the  form 

structure  rec  Xi  :  Si  =  Mi  and  .  .  .  and  X„  :  =  M„ 

but  I  was  deliberately  vague  about  both  the  static  and  dynamic  semantics  of  this  binding  form, 
relying  instead  on  the  reader’s  intuition.  In  this  section  we  will  delve  deeper  into  the  semantics  of 
recursive  modules  and  discover  that  it  is  in  fact  quite  difficult  to  explain  formally  what  the  “right” 
semantics  should  be.  Along  the  way,  I  will  introduce  the  reader  to  a  number  of  key  concepts  and 
issues  that  arise  in  the  design  of  a  recursive  module  extension.  These  will  serve  as  helpful  guides 
in  the  discussion  of  the  existing  recursive  module  proposals  in  Section  5.3  and  of  my  own  recursive 
module  proposal  in  Section  5.4. 

5.2.1  Dynamic  Semantics 

Consider  extending  the  module  system  of  Chapter  4  with  a  new  recursive  construct  rec(X :  S.  M).^ 
The  idea  is  that  X  is  the  module  variable  by  which  the  module  M  refers  to  itself  recursively.  The 
signature  S  is  needed  for  two  reasons:  (1)  to  know  what  signature  to  assign  to  X  while  typechecking 
M,  and  (2)  to  have  a  signature  to  assign  to  the  recursive  module  itself,  since  the  principal  signature 
of  M  may  very  well  refer  to  the  bound  variable  X.  (Note:  this  implies  that  S  should  be  well-formed 
outside  the  recursive  module  and  therefore  not  refer  to  X.)  Some  terminology:  I  will  refer  to  X  as 
the  recursive  (module)  variable,  S  as  the  declared  signature,  and  M  as  the  recursive  module  body. 

Let  us  begin  by  focusing  on  the  dynamic  semantics  of  this  recursive  construct.  Formally  speak¬ 
ing,  in  the  way  I  have  organized  my  module  type  system,  modules  are  evaluated  by  first  phase- 
splitting  them  and  then  evaluating  the  results  according  to  the  core-language  dynamic  semantics. 
However,  that  is  primarily  a  technical  device,  allowing  me  to  describe  module  compilation  and 
prove  type  safety  in  one  fell  swoop.  There  should  always  be  some  intuitive  way  of  explaining  how 
modules  are  evaluated. 

So,  intuitively,  how  should  rec(X :  S.  M)  be  evaluated?  Under  the  standard  interpretation  of  re¬ 
cursion  via  a  fixed-point  operator,  rec(X  :  S.  M)  should  evaluate  to  its  “unrolling”  M[rec(X :  S.  M)/X]. 

^While  this  construct  only  defines  a  single  recursive  module,  mutually  recursive  modules  are  definable  by  writing 
them  as  substructures  of  a  single  recursive  module.  Examples  of  this  are  shown  below. 
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rec  (X  :  SIG. 
struct 

structure  A  =  struct 
val  debug  =  ref  false 
fun  f (x)  =  . . .X.B.g(x-l) . . . 
end 

structure  B  =  struct 
val  trace  =  ref  false 
fun  g(x)  =  . . .X. A.f (x-1) . . . 
end 
end) 

Figure  5.6;  Example  of  Recursive  Module  with  Effects 


Such  a  fixed-point  semantics  has  the  property  that  M  is  effectively  re-evaluated  at  every  recursive 
reference  to  X. 

There  is  nothing  inherently  wrong  with  this  behavior,  and  it  will  work  fine  for  some  purely 
functional  recursive  modules,  such  as  the  examples  I  gave  in  Section  5.1.  It  is  undesirable,  though, 
for  recursive  modules  that  contain  computational  effects.  For  example,  consider  the  definition  of  two 
mutually  recursive  structures  A  and  B  shown  in  Figure  5.6.  Here,  debug  and  trace  are  externally- 
accessible  debugging  flags  used  by  f  and  g,  respectively.  Under  a  fixed-point  semantics  for  recursive 
modules,  every  recursive  reference  between  f  and  g  prompts  a  re-evaluation  of  the  entire  module, 
including  the  creation  of  brand  new  ref  cells  for  debug  and  trace.  In  other  words,  each  recursive 
call  operates  in  an  entirely  different  mutable  state,  so  setting  debug  to  true  externally  would  not 
alter  the  fact  that  ! debug  is  false  during  all  recursive  calls  to  X.A.f  and  X.B.g. 

An  alternative  semantics  for  recursion  that  exhibits  more  appropriate  behavior  with  respect 
to  computational  effects  is  the  backpatching  semantics  used  by  Scheme  [38],  in  which  rec(X:S.M) 
would  evaluate  as  follows:  First,  X  is  bound  to  a  fresh  location  containing  an  undefined  value; 
then,  M  is  evaluated  to  a  module  value  V;  finally,  X  is  backpatched  with  V.  If  the  evaluation  of  M 
attempts  to  access  the  value  of  X,  an  error  is  reported.  I  described  backpatching  in  Section  5.1  as 
one  of  the  workarounds  that  programmers  use  in  the  absence  of  recursive  modules,  but  here  it  is 
employed  “behind  the  scenes,”  not  explicitly  by  the  programmer.  Unlike  the  fixed-point  semantics, 
backpatching  has  the  advantage  that  it  ensures  the  effects  in  M  will  only  happen  once. 

Under  a  backpatching  semantics,  the  question  arises:  How  should  we  ensure  that  the  recursion 
is  “safe,”  i.e.,  that  the  evaluation  of  M  will  not  attempt  to  use  the  recursive  variable  X?  Should 
we  try  to  determine  it  statically,  reporting  an  error  at  compile  time  if  we  cannot,  or  should  we 
just  insert  a  dynamic  check  at  each  use  of  X  to  make  sure  it  has  been  backpatched?  There  is  a 
common  tradeoff  here.  The  static  approach  allows  for  more  efficient  implementation,  and  compile¬ 
time  detection  is  certainly  preferable.  On  the  other  hand,  any  static  method  for  ensuring  safe 
recursion  is  bound  to  be  conservative  and  may  rule  out  perfectly  safe  recursive  modules.  For  the 
time  being,  let  us  assume  dynamic  detection.  I  will  explore  static  detection  further  in  Chapter  7. 

5.2.2  Recursively  Dependent  Signatures 

Recall  the  example  of  the  Expr  and  Bind  modules  from  Figure  5.1.  These  mutually  recursive 
modules  may  be  encoded  in  terms  of  rec(X:S.M)  by  having  M  be  a  pair  module  whose  first 
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sig 

structure  Expr  :  sig 
type  t 

(*  makeLetExpr(b,e)  constructs  "let  b  in  e' 
val  makeLetExpr  :  Bind.t  *  t  ->  t 


*) 


(*  matchLetExpr (e)  returns  S0ME(b,ei) 
val  matchLetExpr  :  t  ->  ([ 


Bind.t 


*  t) 


if  e  is  of  the 
option 


form  "let  b  in  ei"  *) 


val  eval  :  t  ->  t 
end 

structure  Bind  :  sig 
type  t 

(*  makeValBind(v, e)  constructs  "val  v  =  e"  *) 
val  makeValBind  :  var  *  Expr.t  ->  t 

(*  matchValBind(b)  returns  S0ME(v,e)  if  b  is  of  the  form  "val  v  =  e"  *) 
val  matchValBind  :  t  ->  (var  *  Expr.t)  option 


val  eval  :  t  ->  (var  *  Expr.t)  list 
end 
end 


Figure  5.7:  Problematic  Signature  for  Expr  and  Bind 


component  is  Expr  and  whose  second  component  is  Bind.  Joined  into  a  single  module,  Expr  and 
Bind  can  refer  recursively  to  each  other  by  projecting  from  the  recursive  variable  X;  that  is,  Expr 
can  refer  to  Bind  as  X.Bind,  and  Bind  can  refer  to  Expr  as  X.Expr.  In  this  case.  Bind  may  also 
just  refer  to  Expr  directly,  since  Expr  is  dehned  first. 

This  encoding  handles  mutually  recursive  dependencies  between  the  modules,  but  what  do  we 
do  about  recursive  dependencies  in  the  signatures?  In  other  words,  what  do  we  do  if  the  signature 
of  each  module  refers  to  type  components  dehned  in  the  other  module?  These  signatures,  which 
are  presumably  part  of  the  declared  signature  S,  cannot  contain  references  to  the  recursive  variable 
X  because  S  needs  to  be  well-formed  outside  of  the  recursive  module. 

For  example,  suppose  that,  in  addition  to  the  eval  function,  the  Expr  module  were  to  provide 
functions  makeLetExpr  and  matchLetExpr  for  constructing  and  deconstructing  let  expressions 
of  type  Expr.t;  and  that  the  Bind  module  were  similarly  to  provide  functions  makeValBind  and 
matchValBind  for  constructing  and  deconstructing  val  bindings  of  type  Bind.t.  Figure  5.7  shows 
the  resulting  signature  of  the  recursive  module  dehning  Expr  and  Bind.  Note  that  the  types  of 
several  function  components  of  each  submodule  refer  to  the  t  component  of  the  other  submodule. 
The  boxed  references  to  Bind.t  in  the  signature  of  Expr  are  not  well-formed,  since  Bind  is  specified 
after  Expr  in  the  signature. 

This  problem  was  pointed  out  first  by  Crary  et  al.  [6] ,  who  propose  as  a  solution  the  introduction 
of  a  new  signature  form  called  a  “recursively  dependent  signature”  (or  “rds”),  written  pX.S.  The 
idea  is  that  the  bound  variable  X  in  pX.S  is  a  stand-in  for  the  module  that  the  signature  is 
describing.  In  other  words,  a  module  M  belongs  to  pX.S  precisely  when  it  belongs  to  S[M/X].  Note 
that  this  definition  only  applies  when  M  is  projectible,  for  otherwise  the  substitution  of  Fst(M)  for 
X'^  in  S  is  not  valid.  If  M  is  not  projectible,  we  can  coerce  it  to  an  rds  pX.S  by  first  let-binding  it 
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pX.  sig 

structure  Expr 
type  t 

val  makeLetExpr 
val  matchLetExpr 


sig 


X.Bind.t 

*  t  -> 

t  ->  ( 

X.Bind.t 

*  t) 


option 


end 

structure  Bind  :  sig 
type  t 


end 

end 

Figure  5.8;  Recursively  Dependent  Signature  for  Expr  and  Bind 


to  a  variable  Y,  which  is  projectible.  That  is,  we  can  expand  M  into  let  Y  =  M  in  (Y  ;  pX.S). 

Figure  5.8  shows  a  recursively  dependent  signature  that  can  be  used  as  the  declared  signature 
for  the  Expr  and  Bind  modules.  The  rds  provides  a  way  for  the  signature  of  Expr  to  refer  to  Bind .  t, 
namely  by  projecting  it  from  the  bound  variable  X. 

Recursively  dependent  signatures  clearly  add  some  power  to  Mb’s  signature  language,  since  the 
signature  of  Expr  and  Bind  is  not  expressible  without  them.  The  question  is:  do  rds’s  merely  add 
flexibility  to  the  signature  language,  or  does  the  type  structure  of  Mb’s  core  language  need  to  be 
enhanced  in  some  way  in  order  to  be  able  to  support  them,  i.e.,  to  phase-split  them?  The  answer 
to  this  question  depends,  perhaps  unsurprisingly,  on  whether  we  place  any  restrictions  on  the  kinds 
of  recursive  references  to  X  that  are  permitted  to  occur  in  pX.S. 

Suppose  that  we  place  no  restrictions,  and  consider  the  following  rds: 

pX.  sig  type  t  =  int  *  X.t  end 

A  module  M  will  inhabit  this  rds  precisely  when  it  also  inhabits  sig  type  t  =  int  *  M.t  end, 
in  which  case  we  will  be  able  to  observe  that  M . t  is  equivalent  to  int  *  M.t.  The  only  known  way 
to  account  for  this  sort  of  recursive  type  equivalence  is  through  the  use  of  so-called  “equi-recursive” 
type  constructors  [6].  An  equi-recursive  type  constructor  p,a:K.C  has  the  property  that  it  is  the 
unique  fixed-point  of  the  constructor  function  Aa:K.C,  assuming  one  exists.  In  other  words,  pa:K.C 
is  equivalent  to  C[pa:K.C/a],  and  if  D  is  equivalent  to  C[D/a],  then  D  is  equivalent  to  pa:K.C. 
Using  equi-recursive  types,  the  rds  displayed  above  could  be  encoded  as  [5(;UQ;:T.int  x  a)]. 

Unfortunately,  equi-recursive  type  constructors  complicate  the  decision  procedure  for  con¬ 
structor  equivalence  [2],  and  their  interaction  with  singleton  kinds  is  not  well  understood.  Fur¬ 
thermore,  although  the  underlying  type  structure  of  Mb  must  support  some  form  of  recursive 
type  constructor  in  order  to  interpret  recursive  datatype  definitions,  equi-recursive  types  pro¬ 
vide  more  type  equivalences  than  necessary  for  this  purpose.  A  datatype  definition  such  as 
“datatype  t  =  Cons  of  int  *  t”  creates  a  new  abstract  type  t,  and  the  coercions  between  t 
and  int  *  t  are  always  witnessed  at  the  programming  level  by  an  application  of,  or  pattern  match 
against.  Cons.  It  is  therefore  not  important  to  be  able  to  observe  that  t  and  int  *  t  are  equivalent. 

For  the  purpose  of  supporting  Mb’s  recursive  types,  “iso-recursive”  type  constructors  are  suffi¬ 
cient.  Under  an  iso-recursive  semantics,  a  type  like  /ua:T.int  x  a  is  not  equivalent  to  its  unfolding. 
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pX.  sig 

structure  Expr  :  sig 

datatype  t  =  VarExpr  of  var  |  LetExpr  of 


X.Bind.t 


*  t 


end 

structure  Bind  :  sig 

datatype  t  =  . . .  |  ValBind  of  var  *  Expr.t  | 


end 

end 

Figure  5.9:  Rds  for  Expr  and  Bind  with  Mutually  Recursive  Datatype  Specifications 


int  X  (^arT.int  x  a),  but  the  two  types  are  isomorphic  in  the  sense  that  values  of  either  type  can 
be  coerced  into  the  other  type  by  a  “fold”  or  “unfold”  operation.^  Iso-recursive  type  constructors 
have  the  advantage  that  they  rely  on  a  very  simple  equational  theory,  which  is  easy  to  incorporate 
into  a  core  language  with  singleton  kinds.  They  are  not  capable,  however,  of  supporting  the  equa¬ 
tional  reasoning  implied  by  unrestricted  rds’s  like  the  one  shown  above.  If  we  want  to  avoid  the 
need  for  equi-recursive  types,  we  need  to  impose  some  restrictions  on  rds’s. 

A  simple  restriction  to  pX.S  that  was  suggested  by  Crary  et  al.  [6]  as  a  way  of  avoiding  equi- 
recursive  types  is  to  only  permit  references  to  X  in  S  if  they  occur  within  the  types  of  value 
components — references  to  X  in  the  (singleton)  kinds  of  type  components  are  disallowed.  This 
prevents  one  from  writing  the  unrestricted  rds  shown  above,  since  that  rds  contains  a  reference  to 
X  in  the  transparent  specihcation — i.e.,  the  singleton  kind — of  the  t  component. 

Viewed  in  the  terms  of  my  module  type  system,  this  restriction  has  the  effect  that  X*^  cannot 
appear  in  the  free  variables  of  Fst(S).  As  a  result,  it  is  possible  to  phase-split  such  rds’s  into  the 
core  language  without  requiring  any  recursive  types.  In  particular,  here  is  the  phase-splitting  rule; 

S  =1  |a:K.C] 
pX.S  ^  [a;K.C[a/X"]| 

To  understand  why  this  rule  makes  sense,  observe  that  the  restriction  described  above  requires  all 
references  to  X'’’  in  S  to  be  from  types  appearing  in  C  (the  dynamic  part  of  S)  to  types  specihed  by 
K  (the  static  part  of  S).  (Crary  et  al.  refer  to  this  restriction  as  a  “dynamic-on-static”  restriction.) 
Thus,  when  we  phase-split  S,  and  the  static  and  dynamic  parts  of  S  are  separated,  what  were  once 
“recursive”  references  to  X'’’  in  C  can  be  replaced  by  direct  references  to  a. 

How  prohibitive  is  the  dynamic-on-static  restriction?  The  original  rds  for  Expr  and  Bind  shown 
in  Figure  5.8  is  well-formed  under  it,  but  what  about  the  rds  shown  in  Figure  5.9,  in  which  the 
datatype  definitions  of  Expr.t  and  Bind.t  are  exposed?  Since  this  signature  contains  a  recursive 
reference  to  X  in  the  specification  of  the  type  Expr.t,  it  would  appear  to  be  disallowed  under  the 
dynamic-on-static  restriction. 

Fortunately,  though,  it  is  not  disallowed,  because  a  datatype  specihcation  is  not  the  same 
as  a  transparent  type  specihcation.  Rather,  as  discussed  above,  datatype’s  are  abstract — an  ML 
datatype  specihcation  for  t  may  be  viewed  as  an  opaque  type  specihcation  type  t,  together  with  a 

^At  higher  kind,  the  semantics  of  iso-recursive  type  constructors  becomes  more  difficult  to  explain,  but  I  will  do 
so  precisely  in  Chapter  6. 


5.2.  KEY  ISSUES  IN  THE  DESIGN  OF  A  RECURSIVE  MODULE  EXTENSION 


97 


sequence  of  value  specifications  for  each  of  the  constructors — i.e.,  the  branches — of  the  datatype.^ 
The  datatype  specification  for  Expr.t  implicitly  introduces  a  value  specification  for  each  of  its 
data  constructors,  including  one  for  the  function  LetExpr,  which  has  type  X. Bind. t  *  t  ->  t.  It 
is  in  the  specification  of  LetExpr  (and  the  other  data  constructors)  that  the  recursive  references 
to  X  occur,  not  in  the  specification  of  the  type  component  t  itself.  Thus,  we  see  that  “datatype- 
on-static”  recursive  dependencies  are  really  just  a  special  case  of  dynamic-on-static  dependencies. 
This  makes  dynamic-on-static  rds’s  flexible  enough  to  encode  the  signatures  for  all  the  motivating 
examples  from  Section  5.1. 

Nevertheless,  there  are  rds’s  that  are  understandable  in  terms  of  the  existing  ML  core  language — 
i.e.,  without  requiring  the  addition  of  equi-recursive  types — but  which  the  dynamic-on-static  re¬ 
striction  does  not  permit.  For  instance,  consider  the  following  rds: 

pX.  sig 

structure  A  :  sig  type  t  ;  type  u  =  X.B.u  ;  ...  end 
structure  B  :  sig  type  t  ;  type  u  =  A.t  *  t  ;  ...  end 
end 

While  the  definition  of  A .  u  refers  to  X,  it  does  not  introduce  any  truly  cyclic  dependencies  at  the 
level  of  individual  type  components.  Specifically,  A .  u  depends  on  B .  u,  but  B .  u  only  depends  on  the 
opaque  types  A.t  and  B.t,  not  on  A.u.  Correspondingly,  some  recursive  module  proposals  loosen 
the  dynamic-on-static  restriction  to  permit  recursive  dependencies  in  transparent  type  specifications 
as  well,  so  long  as  they  are  fundamentally  acyclic. 

On  the  other  hand,  the  vanilla  dynamic-on-static  restriction  has  the  benefit  that  it  is  very 
simple  to  explain  type-theoretically.  In  particular,  the  well-formedness  rule  for  dynamic-on-static 
rds’s  can  be  written  as  follows: 

A,XFFst(S)  h  S  sig 
A  h  pX.S  sig 

Note  that  the  premise  of  this  rule  implies  that  the  context  A,X'’:Fst(S)  is  well-formed.  This  in 
turn  implies  that  Fst(S)  is  well-formed  in  the  ambient  context  A,  which  is  the  essence  of  the 
dynamic-on-static  restriction. 

5.2.3  The  Double  Vision  Problem 

Having  considered  the  well-formedness  of  recursively  dependent  signatures,  let  us  now  consider  the 
well-formedness  of  recursive  modules.  A  natural  typing  rule  for  rec(X  :  S.  M)  would  be 

r,XTS  F  M  S 
T  F  rec(X:S.M)  S 

which  checks  that  the  recursive  module  body  matches  its  declared  signature.  The  new  context 
binding  form  X  |  S  is  needed  because  recursive  variables  are  compiled  differently  from  ordinary 
variables.  In  particular,  X  is  represented  not  as  a  value  of  signature  S,  but  as  a  memory  location 
that  will  eventually  be  backpatched  with  a  value  of  signature  S.  Correspondingly,  references  to  X 
in  M  are  not  values  either — they  are  computations  that  must  implicitly  check  whether  X  has  been 
backpatched  and,  if  so,  return  its  contents. 

®In  addition,  a  datatype  specification  implicitly  specifies  a  fnnction  that  enables  a  value  of  type  t  to  be  pattern- 
matched.  The  interpretation  of  ML  datatype  specifications  presented  here,  which  is  based  on  Harper  and  Stone’s 
treatment  of  SML  semantics,  will  be  formalized  explicitly  in  the  language  definition  of  Chapter  9. 
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rec  (X  :  EXPR_BIND. 
let  structure  Body  = 
struct 

structure  Expr  : >  sig  type  t  ...  end  =  struct 

datatype  t  =  VarExpr  of  var  |  LetExpr  of  X.Bind.t  *  t  |  . . . 


fun  makeLetExpr  (b 


X.Bind.t 


e 


t) 


t  =  LetExpr (b,e) 


t) 


t  = 


fun  eval  (e 
case  e  of  ... 

I  LetExpr  (b,e)  => 

let  val  (vs,es)  =  List. unzip  (X. Bind. eval  b) 
(*  vs  :  var  list,  es 


X . Expr . t 


list  *) 


in 

end 


end 

structure  Bind  : >  sig  type  t  ...  end  =  . . . 
end 

in  Body  :>  EXPR_BIND 
end) 


Figure  5.10;  The  Double  Vision  Problem  Arising  in  Expr  and  Bind 


Unfortunately,  this  rule  is  too  simple — it  fails  to  accept  many  recursive  modules  whose  declared 
signatures  contain  opaque  type  specifications,  including  both  the  ExprBind  example  and  the  boot¬ 
strapped  heap  example  from  Section  5.1.  Consider  the  code  excerpt  from  the  recursive  module 
defining  Expr  and  Bind,  shown  in  Figure  5.10.  In  this  version,  the  recursive  module  body  is  let- 
bound  to  a  variable  Body,  which  is  then  sealed  with  the  declared  rds  EXPR_BIND.  I  have  written  the 
example  this  way  primarily  so  that  we  have  explicit  names  for  the  types  defined  in  the  body,  e.g., 
Body. Expr. t  and  Body. Bind. t.  The  declared  signature  EXPR_BIND  is  meant  to  stand  for  either 
one  of  the  rds’s  given  in  Figures  5.8  and  5.9.  Whichever  rds  is  used,  the  type  specifications  in  it  are 
opaque.  Consequently,  when  typechecking  the  recursive  module  body,  there  is  no  way  to  connect 
the  abstract  type  components  of  the  recursive  variable  X — namely,  X.Expr.t  and  X.Bind.t — with 
the  corresponding  type  components  of  Body.  This  results  in  several  serious  typing  difficulties. 

In  order  to  understand  these  typing  difficulties,  let  us  first  clarify  what  the  typing  rule  actually 
requires.  Assuming  that  the  rds  EXPR_BIND  has  the  form  pX.S,  the  typing  rule  says  that  Body 
must  match  pX.S,  which  means  in  turn  that  Body  must  match  the  signature  S[Body/X]. 

The  first  problem  is  that  the  Body.  Expr  .makeLetExpr  function  does  not  match  its  required 
type.  This  function  constructs  a  let  expression  of  type  Body. Expr. t  from  a  binding  of  type 
X.Bind.t  and  an  expression  of  type  Body.  Expr.  t.  However,  in  order  for  Body  to  match  S[Body/X], 
the  first  argument  of  Body .  Expr . makeLetExpr  must  have  type  Body .  Bind .  t,  not  X .  Bind .  t.  There 
is  no  simple  way  of  addressing  this  problem — at  the  point  where  makeLetExpr  is  defined,  the  type 
Body  .Bind,  t  does  not  even  exist  yet!  One  might  suggest  switching  the  order  of  Expr  and  Bind,  so 
that  Expr  can  refer  to  Bind  directly,  but  then  the  same  problem  would  rear  its  head  again  when 
matching  Body  .Bind.  makeValBind  against  its  required  type. 
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A  second,  more  subtle  problem  arises  in  typechecking  the  body  of  the  Expr .  eval  function. 
When  the  input  to  this  function  is  of  the  form  LetExpr(b,e),  the  function  makes  a  recursive 
call  to  X. Bind. eval  in  order  to  process  the  binding  b.  The  return  type  of  X. Bind. eval  is 
(var  *  X.Expr.t)  list;  this  list  is  then  unzipped  into  a  list  (vs)  of  the  variables  bound  by  b, 
and  a  list  (es)  of  the  value  expressions  to  which  they  are  bound.  That  the  expressions  in  es  have 
type  X .  Expr .  t  is  problematic  for  several  reasons. 

For  one,  the  implementation  of  eval  may  want  to  deconstruct  these  expressions.  Since  they  have 
type  X .  Expr .  t,  however,  the  only  way  to  deconstruct  them  is  to  call  the  match  functions  provided  by 
X.Expr,  which  is  not  as  efficient  or  convenient  as  case-analyzing  a  value  of  the  datatype  t  directly. 
Moreover,  this  problem  forces  the  Expr  module  to  provide  deconstructor  functions  (or  else  expose 
the  datatype  definition  of  t)  in  its  interface,  regardless  of  whether  it  otherwise  needs  to. 

In  addition,  suppose  that  the  body  e  of  the  input  expression  LetExpr(b,e)  has  the  form 
VarExpr  (v) ,  where  v  is  one  of  the  variables  bound  in  b.  Presumably,  in  this  case,  the  eval  function 
should  return  the  value  expression  in  es  that  corresponds  to  v.  Yet,  the  type  of  that  expression 
will  be  X.Expr.t,  whereas  the  required  return  type  of  eval  is  Body. Expr. t.  The  interface  of  X 
does  not  provide  any  way  to  coerce  a  value  from  X .  Expr .  t  to  Body .  Expr .  t  or  vice  versa. 

All  of  these  typing  difficulties  are  symptoms  of  what  I  call  the  “double  vision  problem.”  This 
problem  is  easiest  to  understand  by  thinking  of  Expr  and  Bind  as  being  written,  respectively,  by  two 
“agents”  (or  “principals” )  Alice  and  Bob  [24] .  Alice  knows  that  the  type  Expr .  t  is  implemented  by 
the  datatype  definition  shown  in  Figure  5.10,  but  Bob  does  not  know  this  because  it  is  not  revealed 
in  the  interface  for  Expr  that  Alice  provides.  Similarly,  Bob  knows  how  Bind.t  is  implemented, 
but  Alice  does  not. 

In  order  to  allow  recursive  references  between  the  two  modules,  we  have  introduced  the  recursive 
variable  X.  Intuitively,  since  X  will  ultimately  be  backpatched  with  the  result  of  evaluating  the  body, 
what  either  agent  knows  about  the  type  components  of  X  should  coincide  with  what  she  knows 
about  the  definitions  of  the  corresponding  type  components  in  the  body.  Thus,  Alice  should  be 
allowed  to  know  that  X .  Expr .  t  is  implemented  in  the  same  way  that  she  has  implemented  Expr .  t 
in  the  body,  and  Bob  should  be  allowed  to  know  that  X. Bind.t  is  implemented  in  the  same  way 
that  he  has  implemented  Bind.t  in  the  body.  Neither  agent,  however,  should  be  allowed  to  know 
how  the  other  agent’s  submodule  of  X  is  implemented.  In  addition,  since  Bob  can  refer  to  Expr.t 
in  two  ways — either  directly  or  through  X — he  should  be  able  to  observe  that  the  two  types  Expr .  t 
and  X.Expr.t  coincide,  without  knowing  what  their  underlying  definition  is. 

The  double  vision  problem  is  that  the  simple  typing  rule  given  at  the  beginning  of  this  section 
fails  to  realize  this  intuition.  Alice  and  Bob  are  shown  the  same  interface  for  the  recursive  variable. 
If  Alice  wants  to  hide  the  identity  of  X.Expr.t  from  Bob,  she  must  also  hide  it  from  herself.  As  a 
result,  she  “sees  double” — that  is,  she  sees  X.Expr.t  as  being  distinct  from  her  own  definition  of 
Expr.t,  and  she  cannot  tell  that  they  are  really  one  and  the  same  type.  Bob  also  sees  two  versions 
of  Expr.t,  although  he  is  not  privy  to  a  definition  for  either  type. 

One  way  to  keep  the  simple  typing  rule  and  avoid  double  vision  is  to  require  that  the  declared 
signature  of  the  recursive  module  be  transparent.  For  example,  if  X .  Expr .  t  were  revealed  in  the  de¬ 
clared  signature  to  equal  some  type  C,  then  Alice  would  be  able  to  observe  that  X.Expr.t  coincides 
with  its  implementation  C.  Of  course,  Bob  would  be  able  to  observe  this  as  well.  Transparency 
addresses  the  double  vision  problem,  but  at  the  expense  of  preventing  Expr  and  Bind  from  hiding 
type  information  from  each  other.  Furthermore,  this  solution  assumes  that  the  programmer  is  able 
to  write  a  transparent  declared  signature.  In  the  case  of  Expr  and  Bind,  the  best  that  we  can  do  is 
modify  EXPR_BIND  so  that  it  exposes  the  datatype  definitions  of  Expr.t  and  Bind.t.  According 
to  ML  semantics,  though,  datatype  specifications  are  opaque. 
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functor  F_Expr  (X  :  EXPR_BIND)  =  .  .  . 

functor  F_Bind  (X  :  EXPR_BIND)  =  .  .  . 

structure  Link  =  rec  (X  :  EXPR_BIND. 
struct 

structure  Expr  =  F_Expr(X) 
structure  Bind  =  F_Bind(X) 
end 

Figure  5.11:  Attempted  Separate  Compilation  of  Expr  and  Bind 


The  double  vision  problem  is  one  of  the  most  serious  hurdles  to  overcome  in  designing  a  recursive 
module  extension.  In  Section  5.3,  I  will  discuss  the  conservative  ways  in  which  the  existing  recursive 
module  proposals  deal  with  it.  A  key  contribution  of  my  own  recursive  module  design,  which  I 
describe  in  Section  5.4,  is  to  provide  a  more  general  and  effective  cure  for  double  vision. 

5.2.4  Separate  Compilation 

One  of  the  main  motivations  for  recursive  modules  is  to  allow  mutually  recursive  functions  and 
data  types  to  be  broken  into  separate,  mutually  recursive  modules.  The  recursive  module  construct 
rec(X :  S.  M)  makes  it  possible  to  write  mutually  recursive  modules,  but  the  modules  must  still  be 
written  together  in  one  place.  What  is  often  desired  in  practice,  however,  is  something  stronger: 
the  ability  to  compile  mutually  recursive  modules  separately. 

Separate  compilation  is  supported  in  ML  via  the  functor  mechanism.  If  a  module  A  depends  on 
a  module  B  of  signature  SIG_B,  then  A  can  be  separately  compiled  from  B  by  defining  it  as  a  functor 
F_A  parameterized  over  a  module  of  signature  SIG_B.  Later,  when  the  program  components  are 
to  be  linked  together,  the  A  module  can  be  defined  by  applying  F_A  to  the  actual  B  module. 

Suppose  that  we  try  compiling  Expr  and  Bind  separately,  as  shown  in  Figure  5.11,  by  turning 
each  module  into  a  functor  that  is  parameterized  over  the  recursive  variable  X.  To  link  the  modules, 
we  write  a  recursive  module  whose  substructures  Expr  and  Bind  are  defined  by  instantiating  the 
respective  functors  with  the  actual  recursive  variable  X. 

One  problem  with  this  approach  is  that,  since  ML  is  call-by- value,  the  occurrences  of  the 
recursive  variable  X  as  an  argument  to  F_Expr  and  F_Bind  will  result  in  an  attempt  to  evaluate 
X  before  the  body  of  Link  is  finished  evaluating.  Thus,  according  to  the  backpatching  semantics 
for  recursive  modules,  the  evaluation  of  the  Link  module  will  raise  an  error  indicating  that  the 
recursion  is  unsafe.  The  issue  here  is  that,  under  the  dynamic  semantics  I  described  in  Section  5.2.1, 
the  memory  location  to  which  X  is  bound  is  implicitly  dereferenced  wherever  X  appears  in  the 
recursive  module  body.  In  the  separate  compilation  scenario,  though,  this  is  clearly  not  the  intended 
semantics.  Instead,  where  X  is  passed  to  F_Expr  and  F_Bind,  we  would  like  to  pass  the  memory 
location  to  which  X  is  bound  without  dereferencing  it. 

There  is  a  relatively  simple  way  of  addressing  this  problem,  which  is  to  make  the  act  of  deref¬ 
erencing  a  recursive  variable  explicit.  First,  we  introduce  a  new  signature  maybe(S)  describing 
modules  of  signature  S  that  may  or  may  not  be  defined.  A  value  of  signature  maybe(S)  is  a  mem¬ 
ory  location  whose  contents  (of  signature  S)  are  in  the  process  of  being  computed.  Then,  rather 
than  treating  the  recursive  variable  X  in  rec(X :  S.  M)  as  a  (non- value)  module  expression  of  signa- 
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ture  S,  we  can  treat  X  as  a  value  of  signature  maybe(S)  that  must  be  explicitly  dereferenced  by 
writing  fetch  (X). 

Given  this  new  form  of  signature,  we  can  rewrite  the  recursive  module  typing  rule  from  Sec¬ 
tion  5.2.3  as  follows; 

r,X:maybe(S)  h  M  S 
r  h  rec(X:S.M)  S 

With  this  semantic  modification,  the  Link  module  in  Figure  5.11  will  no  longer  attempt  to  deref¬ 
erence  X.  In  order  for  the  functor  applications  defining  Expr  and  Bind  to  be  well-formed,  though, 
we  must:  (1)  change  the  argument  signature  of  F_Expr  and  F_Bind  to  maybe(EXPR_BIND),  and 
(2)  replace  references  to  X  in  the  bodies  of  those  functors  with  fetch  (X). 

Unfortunately,  this  new  typing  rule  still  runs  afoul  of  the  double  vision  problem.  In  particular, 
just  as  when  Expr  and  Bind  were  defined  together  in  Figure  5.10,  there  is  no  way  in  the  body 
of  F_Expr  to  connect  X.Expr.t  with  the  implementation  of  t  that  the  body  of  F_Expr  provides. 
Separate  compilation  certainly  does  not  make  the  problem  any  easier. 


5.3  Existing  Approaches  to  Recursive  Modules 

In  Sections  5.3. 1-5. 3. 3,  I  describe  the  existing  proposals  for  extending  ML  with  recursive  modules. 
I  will  discuss  the  strengths  and  weaknesses  of  these  proposals  in  terms  of  how  they  cope  with  the 
issues  surveyed  in  the  previous  section,  especially  the  double  vision  problem.  In  Sections  5.3.4 
and  5.3.5,  I  survey  some  alternative  approaches  to  cross-module  recursion  that  involve  replacing 
ML’s  mechanisms  for  modular  composition  with  something  significantly  different. 

5.3.1  A  Foundational  Account 

Crary,  Harper  and  Puri  [6]  (hereafter,  CHP)  give  a  foundational,  type-theoretic  account  of  the 
recursive  module  problem.  They  are  responsible  for  a  number  of  the  important  ideas  presented  in 
Section  5.2.  In  particular,  they  introduced  the  concept  of  recursively  dependent  signatures,  and 
were  the  first  to  identify  the  double  vision  problem  (although  they  do  not  call  it  that). 

The  actual  type  system  that  CHP  define  is  more  of  a  language  sketch  than  it  is  a  full-fledged 
ML  extension.  It  is  built  on  top  of  Harper,  Mitchell  and  Moggi’s  phase-distinction  calculus  [30].  It 
supports  translucency,  as  I  did  in  Chapter  3,  by  extending  the  HMM  core  language  with  singleton 
kinds,  but  it  does  not  support  any  form  of  sealing.  The  type  system  also  includes  equi-recursive 
type  constructors,  but  the  question  of  decidability  of  type  checking  is  left  to  future  work. 

The  CHP  type  system  employs  a  fixed-point  semantics  for  recursion,  which  is  made  possible  by 
their  restriction  that  the  body  of  a  recursive  module  be  “valuable,”  i.e.,  effect-free  and  terminating. 
This  places  a  significant  limitation  on  the  kinds  of  recursive  modules  one  can  write.  For  example, 
the  recursive  module  in  Figure  5.6  is  not  expressible. 

CHP’s  approach  to  the  double  vision  problem  is  to  require  that  the  declared  signature  of  a 
recursive  module  be  transparent.  In  order  to  allow  datatype  specifications  to  occur  in  a  trans¬ 
parent  signature,  CHP  rely  on  a  “transparent  interpretation”  of  ML  datatype’s.  Under  such  an 
interpretation,  a  datatype  specification  for  t  specifies  the  type  t  as  being  transparently  equal  to  a 
particular  recursive  type,  instead  of  leaving  the  identity  of  t  abstract.  First  of  all,  it  is  difficult  to 
reconcile  the  transparent  interpretation  of  datatype’s  with  ML’s  semantics,  in  which  datatype’s 
are  abstract  types.  (See  Vanderwaart  et  al.  [79]  for  a  thorough  analysis  of  this  issue.)  Moreover, 
requiring  the  signature  of  a  recursive  module  to  be  transparent  stymies  the  enforcement  of  any  data 
abstraction  between  mutually  recursive  submodules,  like  Expr  and  Bind. 
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CHP  propose  the  use  of  functors  for  separate  compilation  of  recursive  modules,  in  the  manner 
of  the  example  from  Figure  5.11.  As  I  argued  in  Section  5.2.4,  this  approach  only  works  if  we 
introduce  a  distinction  between  the  types  of  recursive  variables  and  the  types  of  ordinary  variables, 
and  make  the  dereferencing  of  recursive  variables  explicit.  CHP  do  not  do  this,  and  consequently 
their  example  of  how  to  support  separate  compilation  does  not  typecheck.  It  would  not  be  hard 
to  fix  this  problem — by  extending  their  system  with  a  new  maybe(S)  signature  as  I  proposed  in 
Section  5.2.4.  Still,  due  to  the  double  vision  problem,  their  approach  would  only  enable  the  separate 
compilation  of  recursive  modules  with  transparent  signatures. 

In  short,  CHP’s  main  contribution  has  been  to  provide  a  conceptual  framework  in  which  the 
recursive  module  problem  may  be  discussed  coherently.  Their  main  limitation  is  that  they  do  not 
resolve  the  double  vision  problem  in  a  satisfactory  way. 

5.3.2  Moscow  ML 

Russo  [66]  has  implemented  a  recursive  module  extension  to  ML  in  the  context  of  the  Moscow  ML 
compiler  [56].  This  is  the  first  recursive  module  extension  to  be  actually  implemented.  Inspired 
by  CHP,  Russo’s  extension  introduces  a  recursive  module  construct  and  an  rds  construct.  The 
rds  construct  is  subject  to  the  relaxed  form  of  the  dynamic-on-static  restriction  (described  in 
Section  5.2.2),  in  which  recursive  references  in  transparent  type  specifications  are  permitted,  but 
only  if  they  are  acyclic.  Russo’s  rds  construct  is  written  rec(X: 81)82,  where  Si  serves  as  the 
signature  of  X  when  checking  the  well-formedness  of  82.  It  is  not  clear  why  the  programmer  is 
required  to  write  Si  instead  of  simply  having  the  type  system  infer  it  from  82.^ 

Russo’s  recursive  module  construct  has  the  same  form  as  the  one  studied  in  Section  5.2.  He 
employs  a  backpatching  semantics  and  relies  on  dynamic  checks  to  ensure  that  the  recursion  is 
safe.  The  body  of  a  recursive  module  may  therefore  have  arbitrary  computational  effects,  and 
these  effects  are  guaranteed  to  only  happen  once. 

Russo’s  typing  rule  for  rec(X :  8.  M)  differs  from  any  of  the  typing  rules  considered  in  Section  5.2. 
First,  it  allows  M  to  provide  components  that  are  not  specified  explicitly  in  8.  In  other  words,  8 
is  used  merely  as  a  “forward  declaration”  of  those  components  that  will  be  needed  recursively;  it 
does  not  represent  the  signature  of  the  whole  module.  Second,  M  is  required  to  be  coercible^  to 
the  signature  Ss(X).  This  requirement  is  Russo’s  way  of  avoiding  the  double  vision  problem:  if  M 
is  coercible  to  Ss(X),  then  for  any  type  component  t  specified  by  8,  the  definition  for  t  given  by 
M  must  coincide  with  the  type  X.t. 

Russo’s  solution  to  double  vision  is,  for  the  most  part,  the  same  as  requiring  that  8  be  trans¬ 
parent.  To  illustrate  this,  suppose  that  we  try  to  write  the  ExprBind  example  in  Moscow  ML. 
Figure  5.12  shows  a  first  attempt,  in  which  the  declared  signature  EXPR_BIND  hides  the  datatype 
definitions  of  Expr  .t  and  Bind.t.  8ince  there  is  no  way  to  connect  the  datatype  definitions  in  the 
body  to  the  abstract  types  X.Expr.t  and  X. Bind.t,  the  module  does  not  typecheck.  Generally 
speaking,  under  Russo’s  typing  rule,  if  the  declared  signature  contains  an  opaque  specification  of 
the  form  type  u,  the  only  way  the  body  of  the  recursive  module  will  be  allowed  to  define  u  is 
by  writing  type  u  =  X.u,  in  which  case  u  never  gets  defined!  Thus,  opaque  type  specifications  in 
declared  signatures  are  essentially  useless. 

In  order  to  write  recursive  modules  like  Expr  and  Bind  in  Moscow  ML,  the  programmer  is 
forced  to  expose  the  datatype  definitions  of  Expr.t  and  Bind.t  in  the  declared  signature,  as 
shown  in  Figure  5.13.  We  rely  in  this  version  of  ExprBind  on  a  little-known  feature  of  8tandard 

^As,  for  example,  Leroy’s  extension  to  O’Caml  does  (described  below). 

^According  to  ML’s  notion  of  coercive  signature  matching,  formalized  in  Section  9.3.4. 
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signature  EXPR_BIND  = 
sig 

structure  Expr  :  sig  type  t  ...  end 
structure  Bind  :  sig  type  t  ...  end 
end 

structure  ExprBind  =  rec  (X  :  EXPR_BIND) 
struct 

structure  Expr  =  struct  datatype  t  =  . . .  end 
Type  error:  Expr.t  ^  X.Expr.t  *) 
structure  Bind  =  struct  datatype  t  =  . . .  end 
(*  Type  error:  Bind.t  ^  X.Bind.t  *) 
end 

Figure  5.12:  Expr  and  Bind  in  Moscow  ML:  First  Try 


signature  EXPR_BIND  = 

rec  (X  :  sig  structure  Expr  :  sig  type  t  end 

structure  Bind  :  sig  type  t  end  end) 

sig 

structure  Expr  :  sig  datatype  t  =  . . .  end 

structure  Bind  :  sig  datatype  t  =  . . .  end 

end 

structure  ExprBind  =  rec  (X  :  EXPR_BIND) 
struct 

structure  Expr  =  struct  datatype  t  =  datatype  X.Expr.t  . . .  end 

structure  Bind  =  struct  datatype  t  =  datatype  X.Bind.t  . . .  end 

end 

Figure  5.13:  Expr  and  Bind  in  Moscow  ML:  Second  Try 


ML,  namely  the  datatype  replication  binding.  By  writing  datatype  t  =  datatype  X.Expr.t, 
the  Expr  module  defines  the  type  t  as  equivalent  to  X.Expr.t,  and  also  binds  local  copies  of  all 
of  X.Expr.t’s  data  constructors.  With  this  binding,  the  double  vision  problem  is  clearly  avoided, 
and  the  example  typechecks. 

The  astute  reader  may  have  noticed  that,  even  in  this  successful  attempt  at  Expr  and  Bind, 
the  types  Expr.t  and  Bind.t  are  still  never  defined  anywhere.  The  declared  signature  provides 
datatype  specifications  for  them,  which  indicates  what  the  types  of  their  data  constructors  are, 
but  the  types  themselves  are  abstract  because  datatype  specifications  are  opaque.  Russo  is  not 
clear  on  this  point.  My  interpretation  is  that,  when  a  datatype  specification  (or  any  opaque 
type  specification)  appears  in  the  declared  signature  of  a  recursive  module,  the  compiler  implicitly 
defines  the  type  in  some  canonical  way  that  matches  the  specification.  Since  the  type  is  abstract,  the 
program  will  typecheck  regardless  of  which  canonical  implementation  is  chosen.  See  Section  9.3.3 
for  further  discussion  of  how  to  construct  canonical  implementations  of  certain  specifications. 

To  summarize,  Russo’s  extension  makes  it  possible  to  encode  all  of  the  motivating  examples  from 
Section  5.1,  but  prevents  the  programmer  from  hiding  type  information  between  mutually  recursive 
modules.  This  limitation  is  alleviated  slightly  by  the  fact  that  the  body  of  a  recursive  module  is 
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functor  F_Expr  (X  :  EXPR_BIND)  =  .  .  . 

functor  F_Bind  (X  :  EXPR_BIND)  =  .  .  . 

structure  ExprBind  =  rec  (X  :  EXPR_BIND) 
struct 

structure  EtaX  =  struct 
structure  Expr  =  struct 

datatype  t  =  datatype  X.Expr.t 
fun  eval  e  =  X . Expr . eval  e 

...  (*  define  eta-expansion  for  every  function  *) 
end 

structure  Bind  =  . . .  (*  similarly  for  Bind  *) 
end 

structure  Expr  =  F_  Expr  (EtaX) 
structure  Bind  =  F_  Bind  (EtaX) 
end 

Figure  5.14:  Separate  Compilation  of  Expr  and  Bind  in  Moscow  ML 


allowed  to  define  additional  type  components  that  are  not  specified  in  the  declared  signature.  For 
example,  Expr  and  Bind  are  free  to  define  type  components  other  than  t  and  to  hold  their  identities 
abstract,  but  only  if  those  type  components  do  not  need  to  be  forward-declared  in  the  signature 
of  X.  It  is  hard  to  say  how  useful  this  flexibility  would  be  in  practice. 

Lastly,  with  regard  to  separate  compilation,  Russo  proposes  the  use  of  functors.  Unlike  CHP, 
he  correctly  observes  that  the  separate  compilation  scenario  of  Figure  5.11  does  not  work.  Instead, 
he  suggests  an  alternative  solution  that  only  works  when  all  the  value  components  of  the  recursive 
variable  X  are  functions.  His  solution,  shown  in  Figure  5.14,  is  to  dehne  (in  the  linking  module)  a 
structure  called  EtaX  whose  type  components  are  copies  of  the  type  components  of  X  and  whose 
value  components  are  eta-expansions  of  the  value  components  of  X.  The  modules  Expr  and  Bind 
can  then  be  dehned  by  applying  F_Expr  and  F_Bind,  respectively,  to  EtaX  instead  of  X.  While  this 
solution  does  work  in  the  particular  case  of  Expr  and  Bind,  it  does  not  constitute  a  general  solution. 
Moreover,  from  an  aesthetic  standpoint,  it  is  not  much  of  an  improvement  on  the  recursive  module 
workarounds  discussed  in  Section  5.1. 

5.3.3  O’Caml 

Leroy  has  implemented  recursive  modules  as  an  experimental  extension  to  the  O’Caml  language, 
available  in  version  3.07  of  the  compiler  and  later  [41].  O’Caml  does  not  have  a  formal  definition, 
and  neither  does  its  recursive  module  extension,  but  Leroy  has  made  an  informal  description  of  his 
extension  available  on  the  web  [44]. 

Leroy  introduces  rds’s  via  a  recursively  dependent  module  rec  specification.  Figure  5.15  shows 
how  the  EXPR_BIND  signature  would  be  written  in  O’Caml.  Similarly  to  Moscow  ML,  Leroy  avoids 
the  need  for  equi-recursive  type  constructors  by  prohibiting  cyclic  dependencies  from  occurring  in 
transparent  type  specifications. 

For  recursive  modules,  Leroy  introduces  a  module  rec  binding,  whose  syntax  is  almost  identical 
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module  type  EXPR_BIND  = 
sig 

module  rec  Expr  :  sig 
type  t 

val  makeLetExpr  :  Bind.t  *  t  ->  t 
end 

and  Bind  :  sig 
type  t 

val  makeValBind  :  var  *  Expr.t  ->  t 

end 

end 

Figure  5.15:  Signature  for  Expr  and  Bind  in  O’Caml 


to  the  structure  rec  binding  I  used  in  the  motivating  examples  of  Section  5.1.  The  binding 

module  rec  Xi  :  Si  =  Mi  and  .  .  .  and  X„  :  S^  = 

defines  a  bundle  of  n  mutually  recursive  modules,  Mi,. . .  ,M„,  that  refer  to  one  another  as  Xi,. . .  ,X„. 
The  binding  is  evaluated  according  to  backpatching  semantics.  Leroy  imposes  a  restriction  on  re¬ 
cursive  modules,  though,  that  enables  him  to  implement  backpatching  more  efficiently.  Specifically, 
in  Leroy’s  semantics,  a  module  may  only  be  depended  on  recursively  if  all  of  the  value  components 
in  its  interface  have  “pointed”  type,  i.e.,  they  are  all  functions  or  lazy  computations,  for  which 
there  is  a  canonical  bottom  (T)  element.®  As  a  result,  the  recursive  modules  A  and  B  in  Figure  5.6 
are  not  encodable  in  O’Caml  because  both  modules  have  value  components  of  the  non-pointed  type 
bool  ref.  On  the  other  hand,  O’Caml  does  allow  one  to  write  all  of  the  motivating  examples  from 
Section  5.1. 

To  see  why  Leroy’s  restriction  enables  more  efficient  implementation  of  backpatching,  consider 
the  single  binding  module  rec  X  :  S  =  M.  Under  the  general  backpatching  semantics,  the  con¬ 
tents  of  the  location  X  are  uninitialized  during  the  evaluation  of  M.  Thus,  in  order  to  ensure  type 
safety,  we  must  prevent  X  from  being  dereferenced  until  its  contents  have  been  initialized  via  back- 
patching.  There  are  various  ways  to  ensure  that  X  does  not  get  dereferenced,  but  they  all  involve 
some  run-time  cost.'^  However,  if  S  only  specifies  values  of  pointed  type,  then  there  is  a  canonical 
way  of  constructing  a  “dummy”  module  N  of  signature  S  such  that,  if  any  of  the  functions  in  N 
are  applied  (or  any  of  the  lazy  computations  in  N  are  forced),  an  “unsafe  recursion”  exception  will 
be  raised.  This  dummy  module  N  gives  us  a  way  of  safely  initializing  the  contents  of  X  before 
evaluating  M,  so  there  is  no  need  to  dynamically  protect  against  the  dereferencing  of  X. 

Aside  from  the  pointed-type  restriction,  Leroy’s  typing  rule  for  recursive  modules  is  precisely 
the  simple  typing  rule  suggested  at  the  beginning  of  Section  5.2.3.  As  we  know,  this  typing  rule  runs 
afoul  of  the  double  vision  problem.  Leroy’s  solution  is  somewhat  ad  hoc  and  is  easiest  to  explain 
in  terms  of  the  ExprBind  example.  When  we  are  typechecking  the  body  of  Expr  and  encounter 

®To  be  precise,  Leroy  requires  that  there  be  some  evaluation  ordering  of  the  recursive  modules,  Mi,. . .  ,M„,  such 
that  all  “forward”  references  {i.e.,  references  to  modules  that  have  not  been  evaluated  yet)  are  to  modules  whose 
components  have  pointed  type.  For  more  in-depth  discussion,  see  also  Hirschowitz,  Leroy  and  Wells  [36]. 

’^See  the  beginning  of  Chapter  7  for  more  discussion  of  this  point. 
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module  type  S  =  sig 
type  t 

val  f  :  t  ->  t 
end 

module  rec  X  :  sig  module  A  :  S  end  =  struct 
module  A  :  S  =  struct 
type  t  =  C  of  int 
let  f  (x  :  t)  :  t  =  X.A.f  x 
end 
end 

Figure  5.16:  Strange  Behavior  of  O’Caml  Recursive  Module  Typechecking 


the  datatype  definition  of  t,  the  O’Caml  typechecker  adds  to  the  context  the  assumption  that  t  is 
equivalent  to  X.Expr.t.  This  enables  the  body  of  Expr  to  know  that  X.Expr.t  is  implemented  as 
t,  even  though  the  signature  of  X  does  not  reveal  this.  It  also  allows  Expr  and  Bind  to  be  written 
in  O’Caml  without  forcing  their  datatype  definitions  to  be  exposed  in  their  signatures. 

Leroy’s  approach  to  the  double  vision  problem  is  admirable  in  that,  of  the  existing  approaches, 
it  comes  closest  to  realizing  the  Alice-and-Bob  intuition  that  I  gave  in  Section  5.2.3  for  describing 
how  recursive  module  typechecking  should  interact  with  data  abstraction.  Yet  there  are  two  serious 
problems  with  it.  One  is  that  it  only  appears  to  work  for  type  components  that  are  implemented 
internally  by  datatype  definitions.®  For  instance,  if  Expr.t  were  defined  in  the  body  of  Expr  by 
an  ordinary  type  definition  like  type  t  =  int,  then  the  typechecker  would  not  add  to  the  context 
the  assumption  that  X.Expr.t  was  equivalent  to  int.  Thus,  O’Caml’s  recursive  modules  do  not 
avoid  the  double  vision  problem  in  general.  This  runs  counter  to  intuition  and  gives  preferential 
treatment  to  types  implemented  by  datatype  definitions  for  no  clear  reason. 

Another  problem  is  that  no  type-theoretic  explanation  is  provided  for  what  it  means  to  “add 
a  type-equivalence  assumption  to  the  context”  during  the  typechecking  of  the  recursive  module 
body.  In  Section  5.4.2,  I  will  provide  such  an  explanation  in  the  context  of  my  own  recursive 
module  proposal.  In  the  absence  of  such  an  explanation,  though,  the  O’Caml  approach  can  be 
easily  shown  to  exhibit  strange  behavior.  For  instance,  consider  the  simple,  contrived  recursive 
module  shown  in  Figure  5.16.  The  O’Caml  type  definition  type  t  =  C  of  int  corresponds  to 
datatype  t  =  C  of  int  in  SML.  According  to  the  semantics  Leroy  describes,  once  this  type  defi¬ 
nition  is  processed,  we  are  able  to  observe  that  t  is  equivalent  to  X.A.t.  This  is  important  because 
the  well-formedness  of  f  depends  on  the  equivalence  of  t  and  X.A.t.  However,  if  the  t  annotations 
on  the  domain  and  range  types  of  the  function  f  are  replaced  by  X.A.t  (or  omitted  altogether), 
the  O’Caml  typechecker  complains  that  the  type  of  f  is  X.A.t  ->  X.A.t  and  that  this  type  is  not 
equivalent  to  t  ->  t.  Given  Leroy’s  informal  semantics,  this  type  error  does  not  make  any  sense. 

In  conclusion,  Leroy’s  O’Caml  extension  improves  on  previous  work  in  that  it  allows  for  recursive 
modules  to  hide  type  information  from  one  another.  However,  in  order  to  avoid  the  double  vision 
problem,  the  types  whose  identities  are  hidden  must  be  defined  internally  as  datatype’s.  Leroy’s 
extension  also  supports  more  efficient  implementation  of  recursive  modules,  but  this  comes  at  the 
cost  of  not  being  able  to  write  perfectly  reasonable  recursive  modules  such  as  the  one  in  Figure  5.6. 
Leroy  does  not  address  the  issue  of  separate  compilation. 

®Note:  datatype  definitions  are  written  in  O’Caml  using  the  same  keyword  (type)  as  ordinary  type  definitions, 
but  for  expository  purposes,  I  prefer  to  stick  with  SML  syntax  and  refer  to  them  as  datatype  definitions. 
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5.3.4  Units 

As  is  surely  evident  at  this  point,  extending  ML  with  recursive  modules  is  a  difficult  endeavor.  A 
number  of  researchers  have  thus  investigated  ways  of  replacing  ML’s  notion  of  module  with  some 
alternative  mechanism  for  which  recursive  linking  is  the  norm  and  hierarchical  linking  a  special 
case.  The  two  best-known  alternative  mechanisms  are  units  and  mixins. 

Flatt  and  Felleisen  [20]  introduced  units  as  the  foundation  of  a  module  system  for  the  Scheme 
language.  At  first  glance,  a  unit  appears  to  be  roughly  like  an  ML  functor:  it  requires  some  imports 
and  provides  some  exports.  Unlike  functors,  however,  two  units  can  be  linked  recursively  to  form 
a  compound  unit,  with  the  exports  of  each  unit  being  used  to  satisfy  the  import  requirements  of 
the  other  unit.  Eventually,  once  enough  units  have  been  compounded  together  that  the  resulting 
unit  requires  no  more  imports,  the  compound  unit  can  be  “invoked,”  resulting  in  the  execution  of 
its  initialization  routine. 

Aside  from  the  ability  to  link  units  recursively,  one  fundamental  difference  between  units  and 
ML  modules  is  that  the  interdependencies  between  units  can  only  be  described  externally  to  the 
modules  themselves.  In  ML,  the  implementor  of  a  module  A  may  wish  to  use  the  implementation  of 
sets  provided  by  a  particular  module  FastSet,  and  the  implementor  can  indicate  this  by  referring 
to  FastSet  directly  and  projecting  out  its  components.  With  units,  the  implementor  of  A  can  only 
specify  that  it  wants  some  set  module  as  an  import.  The  burden  of  ensuring  that  A  actually  gets 
linked  to  FastSet  is  shifted  to  whoever  wants  to  use  A.  It  is  worth  noting  that  the  unit  approach  of 
external  linking  is  encodable  in  ML.  In  particular,  one  can  write  every  module  in  an  ML  program 
as  a  functor  parameterized  over  its  imports,  and  use  functor  application  to  perform  explicit  linking. 
This  is  referred  to  as  programming  in  “fully  functorized”  style.  ML’s  direct  implementation-on- 
implementation  dependencies,  on  the  other  hand,  are  not  encodable  using  units. 

Another  fundamental  difference  is  that  units  are  first-class.  They  may  be  compiled  separately 
and  then  linked  dynamically  based  on  run-time  information.  In  the  context  of  a  dynamically-typed 
language  like  Scheme,  a  first-class  module  system  is  ideal,  and  units  have  been  deployed  successfully 
in  the  development  of  the  DrScheme  programming  environment  [19].  In  the  context  of  ML,  though, 
where  modules  have  type  components,  having  a  purely  first-class  module  system  makes  it  difficult 
to  track  the  propagation  of  type  information  effectively.®  Flatt  and  Felleisen  consider  the  extension 
of  Scheme’s  units  to  include  ML-style  type  definitions,  but  their  extension  does  not  include  support 
for  translucency  in  unit  interfaces.  Translucency  is  a  key  feature  of  the  ML  module  system  that  is 
not  worth  abandoning  just  in  order  to  support  first-class,  recursive  modules. 

Having  said  that,  it  is  also  worth  pointing  out  that  Flatt  and  Felleisen’s  extension  of  units  to 
include  type  components  does  not  seem  to  suffer  from  double  vision.  In  particular,  one  way  to 
phrase  the  double  vision  problem  is  that  the  types  classifying  a  recursive  module’s  value  imports 
may  need  to  depend  on  the  abstract  types  that  the  module  exports.  With  recursive  ML-style 
modules,  it  is  not  obvious  how  to  allow  a  module’s  imports  to  depend  on  types  that  the  module 
has  not  yet  defined.  With  “type-enhanced”  units,  though,  this  is  not  an  issue.  A  unit  must  give 
explicit  names  to  both  its  type  imports  and  its  type  exports,  and  the  types  that  classify  a  unit’s 
value  imports  and  exports  are  allowed  to  refer  to  any  of  the  type  imports  or  exports.  As  a  result, 
double  vision  is  avoided.  This  comes,  however,  at  the  cost  of  a  rather  restrictive  and  unwieldy 
syntax,  and  of  a  type  system  whose  inference  rules  are  very  large  and  complex.  It  remains  an 
interesting  direction  for  future  work  to  determine  whether  there  exists  a  simple  type-theoretic  way 
of  explaining  what  units  are  doing,  as  well  as  a  compromise  design  that  balances  the  elegance  and 
translucency  of  ML  modules  with  the  unit  approach  to  avoiding  double  vision. 

®See  Section  1.2.3  for  further  discussion  of  this  point. 
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5.3.5  Mixins 


The  term  “mixin”  refers  to  a  variety  of  modularity  constructs,  all  of  which  are  intended  to  support 
recursive  composition  in  something  resembling  an  object-oriented  (00)  style.  Different  notions  of 
mixins  attempt  to  adapt  different  aspects  of  00  languages  to  a  functional-language  setting. 

It  is  well-known  that  functional  and  00  languages  provide  orthogonal  forms  of  extensibility. 
Functional  languages  make  it  easy  to  define  new  functions  that  operate  over  a  datatype,  while  00 
languages  make  it  easy  to  extend  an  existing  datatype  with  new  branches.  Duggan  and  Sourelis  [15] 
propose  a  mixin  module  extension  to  SML,  whose  goal  is  to  provide  00-style  extensibility  by 
making  it  possible  to  split  the  definition  of  a  single  function  or  datatype  across  module  boundaries. 
A  mixin  module  is  like  an  ML  structure  but  is  divided  into  three  parts:  a  prelude,  a  body,  and 
an  initialization  section.  The  body  may  only  contain  only  datatype  and  fun  bindings.  When  two 
mixin  modules  are  composed,  datatype  (or  fun)  bindings  in  the  bodies  of  each  mixin  that  define 
types  (or  functions)  of  the  same  name  are  merged  together  into  a  single  datatype  (or  fun)  binding. 
The  other  sections  of  the  mixin  are  not  restricted,  and  may  have  arbitrary  effects,  but  they  are  not 
involved  in  the  recursive  merging. 

The  functionality  provided  by  Duggan  and  Sourelis’  mixin  modules  is  orthogonal  to  the  func¬ 
tionality  of  recursive  modules  studied  in  this  chapter.  I  have  been  concerned  here  with  the  ability 
to  split  mutually  recursive  functions  and  datatype’s  into  separate  modules,  not  to  split  different 
cases  of  a  single  function  or  datatype  definition  into  separate  modules.  In  later  work  [16],  the 
authors  propose  the  introduction  of  a  second  “mixlink”  mechanism  for  mixin  composition  that 
is  closer  in  aim  to  the  form  of  recursive  module  linking  studied  here.  This  mixlink  construct  is 
accompanied,  though,  by  a  rather  baroque  set  of  restrictions  on  the  structure  of  the  participating 
mixin  modules.  An  advantage  of  the  recursive  module  extension  I  describe  in  Section  5.4  is  that  the 
restrictions  it  imposes  on  the  programmer  are  easy  to  explain.  It  is  difficult  to  comment  further  on 
Duggan  and  Sourelis’  mixlink,  as  the  authors  describe  its  semantics  only  informally  and  provide 
no  implementation  with  which  to  experiment. 

In  more  recent  work,  Duggan  [14]  has  developed  a  language  of  “recursive  DLL’s”  that  diverges 
significantly  from  the  ML  module  system.  This  is  an  intermediate  language,  not  a  source-level 
language,  whose  main  goal  is  to  support  dynamic  linking  and  loading  of  shared  libraries.  Duggan 
addresses  the  double  vision  problem  in  a  manner  similar  to  O’Caml,  but  the  problem  is  simplified 
by  the  fact  that  Duggan’s  language  only  supports  opaque  datatype-like  bindings,  not  transparent 
type  bindings. 

Ancona  and  Zucca  [4]  propose  a  very  different  kind  of  mixin  module  construct  in  their  CMS  cal¬ 
culus.  CMS’s  mixins  are  actually  very  similar  to  Flatt  and  Felleisen’s  units.  The  main  difference  is 
that  CMS  also  supports  “overriding  with  late  binding”  of  module  components,  a  feature  commonly 
associated  with  00-style  inheritance.  CMS  itself  is  somewhat  impractical:  it  is  purely  functional 
and  call-by-name,  and  its  mixin  modules  do  not  contain  type  components  or  provide  the  ability 
to  define  abstract  data  types.  These  simplifications  allow  CMS  to  avoid  dealing  with  the  complex 
issues  surrounding  the  interaction  of  recursion  with  effects  and  the  double  vision  problem.  There 
have  been  several  proposals  for  making  CMS  more  realistic — adding  support  for  computational 
effects  [3],  and  transferring  CMS  to  a  call-by- value  setting  [35] — but  none  has  yet  attempted  to 
extend  mixin  modules  with  type  components. 
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5.4  A  New  Approach 

In  this  section,  I  describe  at  a  high  level  my  own  proposal  for  extending  ML  with  recursive  modules. 
The  main  distinction  between  my  proposal  and  the  existing  proposals  described  in  Section  5.3  is 
that  mine  offers  a  more  satisfying  solution  to  the  double  vision  problem. 

5.4.1  Overview 

Like  the  existing  recursive  module  extensions,  my  extension  introduces  two  new  constructs:  one 
for  recursive  modules  and  one  for  recursively  dependent  signatures.  For  coherence  of  notation,  I 
will  write  these  constructs  using  syntax  similar  to  Moscow  ML’s.  Recursive  modules  have  the  form 
rec(X:S)M,  and  recursively  dependent  signatures  have  the  form  rec(X)S.^*^ 

The  dynamic  semantics  for  the  recursive  module  construct  rec(X:S)M  is  a  straightforward 
backpatching  semantics.  I  do  not  make  any  restrictions  on  the  declared  signature  as  O’Caml  does, 
nor  do  I  attempt  to  statically  detect  that  the  recursion  is  safe,  i.e.,  that  X  will  not  be  dereferenced 
during  the  evaluation  of  M.  The  problem  of  statically  ensuring  safe  recursion  will  be  considered  in 
Chapter  7. 

For  recursively  dependent  signatures  rec(X)S,  I  impose  the  dynamic-on-static  restriction  de¬ 
scribed  in  Section  5.2.2.  That  is,  I  do  not  allow  any  recursive  references  to  X  within  the  specifications 
of  type  components  in  S,  even  if  such  references  do  not  introduce  any  cyclic  type  specifications. 
The  main  reason  for  this  is  simplicity.  Dynamic-on-static  rds’s  constitute  a  relatively  straightfor¬ 
ward  extension  to  my  type  system  for  modules.  (For  more  details,  see  Chapter  6.)  Finding  a  way 
to  type-theoretically  account  for  O’Caml’s  more  general  rds’s — in  which  recursive  dependencies  in 
type  specifications  are  permitted  so  long  as  they  essentially  acyclic — remains  a  worthwhile  direction 
for  future  work.  Nevertheless,  the  more  restricted  form  of  rds  that  I  provide  is  sufficient  to  encode 
all  of  the  motivating  examples  given  in  this  chapter. 

Where  my  proposal  differs  most  from  the  existing  designs  is  in  the  typechecking  of  recursive 
modules.  Given  a  recursive  module  rec(X:S)M,  I  make  two  simple  restrictions  on  the  body  M, 
described  below.  As  long  as  M  obeys  these  restrictions,  my  static  semantics  ensures  that  the  double 
vision  problem  never  arises. 

The  first  restriction  I  place  on  M  is  a  kind  of  dynamic-on-static  restriction  analogous  to  the  one 
imposed  on  rds’s.  For  an  rds  rec(X)S,  references  to  X  may  occur  in  datatype  specifications,  but 
not  in  transparent  type  specifications.  Similarly,  in  the  recursive  module  rec(X:S)M,  I  allow  X  to 
be  referenced  inside  datatype  bindings,  but  not  inside  transparent  type  bindings,  like  type  t  =  C. 

This  restriction  is  motivated  by  the  desire  to  avoid  the  double  vision  problem  in  all  cases. 
Suppose  that  the  following  code,  in  which  a  recursive  reference  to  X  occurs  in  a  transparent  type 
binding,  were  permitted; 

rec  (X  :  sig  type  t  ...  end) 
struct 

type  t  =  int  *  X.t 
end 

In  order  for  my  semantics  to  avoid  double  vision  here,  it  would  have  to  somehow  ensure  that  the 
body  of  the  module  is  typechecked  in  a  context  where  X.t  =  t  =  int  *  X.t.  This  cyclic  type 
equivalence  would  require  the  introduction  of  equi-recursive  types  into  the  core  language.  The 
dynamic-on-static  restriction  allows  me  to  get  by  without  extending  the  core  language. 

^°Note  that,  unlike  Moscow  ML,  I  do  not  require  any  signature  annotation  on  X  in  the  rds  construct. 
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The  second  restriction  on  the  recursive  module  body  is  that  it  be  phase-separable,  i.e.,  that  it 
have  purity  classifier  P  according  to  the  type  system  of  Chapter  4.  Thus,  the  only  way  that  data 
abstraction  may  be  enforced  in  the  body  of  the  recursive  module  is  through  the  use  of  basic  sealing. 
The  reason  for  this  restriction  is  that,  in  my  formalization  of  recursive  module  typechecking,  I  need 
to  be  able  to  phase-split  the  recursive  module  body  and  extract  its  static  part.  In  general,  this  is 
only  possible  if  the  body  is  separable. 

How  significant  are  these  restrictions?  It  is  difficult  to  say  without  more  experimentation.  At 
the  very  least,  they  do  not  pose  a  problem  for  any  of  the  motivating  examples  given  in  Section  5.1. 
With  only  superficial  syntactic  modifications,  all  of  these  examples  are  expressible  in  my  extension. 

Moreover,  in  return  for  its  restrictions,  my  semantics  improves  on  both  the  Moscow  ML  and 
O’Caml  approaches  in  terms  of  its  support  for  data  abstraction  within  recursive  modules.  For 
instance,  consider  our  running  ExprBind  example.  In  Moscow  ML,  Expr.t  and  Bind.t  must  have 
their  datatype  definitions  exposed  in  the  declared  signature  in  order  for  the  example  to  even 
typecheck.  In  O’Caml,  Expr.t  and  Bind.t  need  not  have  their  datatype  definitions  exposed,  but 
in  order  to  avoid  the  double  vision  problem,  they  must  be  implemented  by  datatype  bindings. 
Under  my  approach,  Expr.t  and  Bind.t  need  not  have  their  definitions  exposed,  and  they  may 
be  implemented  either  by  datatype  bindings  or  by  transparent  type  bindings.  Furthermore,  my 
proposal  is  formally  defined,  whereas  the  O’Caml  extension  is  not. 

Finally,  like  the  existing  recursive  module  extensions,  my  proposal  does  not,  in  its  current  form, 
provide  support  for  separate  compilation  of  mutually  recursive  modules.  The  reason  is  that,  in 
order  to  avoid  the  double  vision  problem,  the  body  of  a  recursive  module  is  typechecked  in  a  very 
special  way,  as  I  describe  below.  If  two  mutually  recursive  modules  A  and  B  are  compiled  separately, 
then  whatever  mechanism  we  use  to  compile  them  must  employ  this  special  form  of  typechecking 
as  well.  (In  particular,  as  discussed  in  Section  5.2.4,  if  we  just  try  to  use  functors,  we  run  into  the 
double  vision  problem  all  over  again.)  Thus,  in  order  to  support  separate  compilation  of  recursive 
modules,  we  must  introduce  a  new  separate  compilation  mechanism  that  is  aware  of  recursive 
module  typechecking.  In  Chapter  10,  I  propose  as  future  work  to  incorporate  such  a  mechanism 
into  the  design  of  a  general  compilation  management  language,  built  on  top  of  ML. 

5.4.2  Elaboration  of  Recursive  Modules 

Recall  that,  under  the  Harper-Stone  approach  to  formalizing  ML,  there  are  two  languages:  the 
external  language  (EL),  namely  ML  (or  the  extension  of  it  that  we  are  defining),  and  the  internal 
language  type  system  (IL),  into  which  the  EL  is  elaborated.  The  purpose  of  the  IL  is  to  encapsulate 
in  type  theory  as  much  of  ML  semantics  as  is  possible. 

After  studying  recursive  modules  for  some  time,  the  only  way  I  have  found  to  cleanly  avoid  the 
double  vision  problem  in  type  theory  is  the  original  approach  I  suggested  in  Section  5.2.3,  namely 
to  require  that  the  declared  signature  of  a  recursive  module  be  transparent.  Thus,  in  the  IL  of  my 
new  ML  dialect,  I  provide  a  recursive  module  construct  rec(X:S.  M),  which  syntactically  restricts 
the  declared  signature  to  be  transparent.  The  typing  rule  for  rec(X :  §.  M)  is  as  follows; 

r,X:maybe(S)  h  M  :p  § 

F  h  rec(X:S.M)  :p  S 

This  is  the  same  as  the  typing  rule  given  in  Section  5.2.4,  except  that  here  I  also  require  that 
M  be  pure/separable. This  purity  condition  poses  no  burden,  for  if  M  is  impure  and  has  the 
transparent  signature  S,  then  we  can  always  coerce  M’s  purity  classifier  to  P  by  writing  purify(M). 


have  taken  the  approach  of  binding  X  with  the  signature  maybe(S),  instead  of  employing  a  special  recursive 
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signature  CSS  =  pX. 
structure  Expr  : 

datatype  t  =  . . 
end 

structure  Bind  : 

datatype  t  =  . . 
end 
end 


sig 

sig 

.  I  LetExpr  of  X.Bind.t  *  t  | 
sig 

.  I  ValBind  of  var  *  Expr.t  | 


Figure  5.17:  Closed  Static  Signature  of  Expr  and  Bind 


In  contrast,  my  EL  recursive  module  construct  rec  (X :  S)  M  does  not  require  S  to  be  transparent. 
This  shifts  the  burden  of  avoiding  the  double  vision  problem  onto  the  elaboration  algorithm.  The 
goal  of  the  final  section  of  this  chapter  is  to  provide  an  informal  understanding  of  how  recursive 
module  elaboration  works.  The  formal  details  are  presented  in  Chapter  9. 

The  “Easy”  Case 

Suppose  that  we  are  given  a  recursive  EL  module  rec(X:S)M,  whose  body  M  obeys  the  dynamic- 
on-static  and  separability  restrictions  described  above.  Let  us  begin  by  considering  how  this  module 
is  elaborated  in  the  “easy”  case  where  M  does  not  contain  any  explicit  uses  of  sealing.  That  is, 
assume  that  the  only  abstract  types  in  M  arise  from  datatype  definitions.  An  example  of  such  a 
module  is  the  version  of  ExprBind  shown  in  Eigure  5.12.  The  figures  accompanying  the  following 
discussion  illustrate  the  output  of  elaboration  for  this  version  of  the  ExprBind  module. 

In  the  absence  of  sealing,  the  basic  idea  in  elaborating  rec(X:S)M  is  to  construct  a  transparent 
signature  S'  that  fills  in  the  opaque  type  specifications  of  S  with  the  definitions  of  those  type 
components  provided  by  M.  In  essence,  S'  will  be  equivalent  to  5s(Fst(M)).  If  we  use  S'  as  the 
declared  signature  of  X  (instead  of  S),  then  we  will  avoid  double  vision  because  we  will  be  able  to 
observe  that  Fst(X)  is  equivalent  to  Fst(M). 

Unfortunately,  in  reality,  we  cannot  directly  use  Ss(Fst(M))  as  the  declared  signature  of  X, 
because  M  may  contain  datatype  bindings  with  recursive  references  to  X.  The  solution  is  to 
first  define  a  module,  called  Static,  which  resolves  the  recursive  dependencies  among  M’s  type 
components  while  ignoring  its  term  components.  We  can  then  use  Static  in  place  of  Fst(M)  in  the 
declared  signature  of  X. 

To  compute  Static,  we  begin  by  generating  a  signature  R,  which  contains  as  precise  a  speci¬ 
fication  of  M’s  type  components  as  possible  and  ignores  its  value  components.  That  is,  for  every 
type  binding  in  M,  type  t  =  C,  there  will  be  a  type  specification  in  R  of  the  form  type  t  =  C; 
for  every  datatype  binding  in  M,  the  corresponding  datatype  specification  will  appear  in  R  as 
well.  Eor  every  val  or  fun  binding  in  M,  no  specification  appears  in  R.  I  will  refer  to  R  as  the 
“static  signature”  of  M. 

The  static  signature  R  may  have  free  recursive  references  to  X.  However,  thanks  to  the  dynamic- 
on-static  restriction  on  M,  these  recursive  references  may  only  appear  within  datatype  specifica¬ 
tions,  not  within  transparent  type  specifications.  Consequently,  the  recursively  dependent  signature 

variable  binding  X  |  S,  both  to  simplify  the  module  meta-theory  and  make  the  construct  more  amenable  to  the 
eventual  support  of  separate  compilation.  Correspondingly,  the  dereferencing  of  X  must  be  indicated  explicitly  in  the 
body  M  by  writing  fetch  (X). 
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structure  Static  :>  CSS  = 
let 

datatype  Expr_t  =  .  .  .  |  LetExpr  of  Bind_t  *  t  |  ... 

and  Bind_t  =  .  .  .  |  ValBind  of  var  *  Expr_t  |  ... 
in 

struct 

structure  Expr  =  struct 

datatype  t  =  datatype  Expr_t 
end 

structure  Bind  =  struct 

datatype  t  =  datatype  Bind_t 
end 
end 

end 

Figure  5.18;  Canonical  Implementation  of  Expr  and  Bind’s  Closed  Static  Signature 


structure  ExprBind  =  rec  (X  :  -5EXPR_BIND(^'*'^^i^)^ 
struct 

structure  Expr  =  struct 

datatype  t  =  . . .  |  LetExpr  of  X.Bind.t  *  t  |  . . . 
(*  Double  vision:  t  ^  X.Expr.t  *) 
end 

structure  Bind  =  struct 

datatype  t  =  . . .  |  ValBind  of  var  *  Expr.t  |  . . . 
(*  Double  vision:  t  ^  X.Bind.t  *) 
end 
end 


Figure  5.19;  Elaboration  of  Expr  and  Bind:  First  Try 


pX.R  is  guaranteed  to  be  well-formed.  I  will  refer  to  this  rds  as  the  ^‘closed  static  signature”  of  M. 
The  closed  static  signature  of  ExprBind  is  shown  in  Figure  5.17. 

Given  the  closed  static  signature  pX.R  of  M,  we  may  now  define  Static  as  the  “canonical” 
module  implementing  this  signature.  The  details  of  computing  canonical  implementations  of  signa¬ 
tures  are  given  in  Section  9.3.3,  but  the  basic  idea  is  straightforward.  We  first  resolve  the  recursive 
references  to  X  in  the  datatype  specifications  of  R  by  joining  all  the  type  components  of  the  module 
in  a  big  datatype  binding.  Once  we  have  done  this,  we  can  copy  the  types  into  the  appropriate 
substructures.  Figure  5.18  illustrates  this  construction  in  the  case  of  Expr  and  Bind. 

Having  defined  Static,  we  can  now  use  5s(Static)  as  the  declared  signature  of  the  recursive 
module.  There  is  one  last  tricky  point,  however,  regarding  datatype’s.  Figure  5.19  shows  what 
goes  wrong  in  the  ExprBind  example  if  we  use  Ss (Static)  as  the  declared  signature  but  leave  the 
recursive  module  body  unchanged.  Specifically,  any  datatype  bindings  in  the  body  will  generate 
fresh  abstract  types  that  are  not  equivalent  to  the  corresponding  components  of  X  or  Static.  The 
solution  is  simple:  replace  every  datatype  binding  in  the  recursive  module  body  with  a  datatype 
replication  binding  that  copies  the  corresponding  datatype  component  from  Static  instead  of 
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structure  ExprBind  =  rec  (X  :  -SgxPR 
struct 

structure  Expr 
datatype  t  = 
end 

structure  Bind 
datatype  t  = 
end 
end 


=  struct 

datatype  Static .Bind. t 


=  struct 

datatype  Static. Expr. t 


Figure  5.20:  Elaboration  of  Expr  and  Bind:  Second  Try 


structure  ExprBind  =  rec  (X  :  -5EXPR_BIND(^'*'^'*'i^)^ 
struct 

structure  Expr  :>  sig  type  t  ...  end  = 

struct  ...  (*  same  as  in  Figure  5.20  *)  ...  end 
structure  Bind  :>  sig  type  t  ...  end  = 

struct  ...  (*  same  as  in  Figure  5.20  *)  ...  end 

end 

Figure  5.21:  Elaboration  of  Expr  and  Bind  With  Sealing:  First  Try 


defining  a  fresh  one.  Figure  5.20  shows  how  this  is  done  for  Expr  and  Bind. 

This  completes  the  discussion  of  recursive  module  elaboration  in  the  case  where  M  contains 
no  sealing.  In  the  interest  of  expository  simplicity,  I  have  glossed  over  a  few  technical  issues.  For 
instance,  it  is  possible  that  the  recursive  module  body  M  defines  more  type  components  than  are 
specified  in  the  declared  signature  S  or  that  it  defines  them  in  a  different  order  than  S  does.  In  this 
case,  while  M  will  be  coercible  to  S  according  to  Mb’s  notion  of  signature  matching,  the  signature 
5s(Static)  will  not  be  well-formed  because  the  kind  of  Fst(Static)  will  not  be  an  IL  subkind  of 
Fst(S).  This  is  not  a  problem  in  practice,  however.  As  long  as  M  is  coercible  to  S,  we  can  generate 
a  type  constructor  Static’  that  copies  and  reorders  (some  of)  the  type  components  of  Static 
in  order  to  match  Fst(S)  precisely.  We  can  then  use  5s(Static’)  instead  of  Ss(Static)  for  the 
declared  signature  of  the  recursive  module.  I  will  leave  discussion  of  other  technical  subtleties  until 
Section  9.3.8,  in  which  recursive  module  elaboration  is  formalized. 

The  General  Case 

We  now  turn  attention  to  the  general  problem  of  elaborating  rec(X:  S)M,  where  the  body  M  may 
contain  uses  of  (basic)  sealing.  To  make  the  problem  concrete,  consider  how  we  might  elaborate 
our  key  motivating  example,  namely  the  version  of  the  ExprBind  module  in  which  Expr  and  Bind 
are  sealed  with  signatures  that  hide  the  data  constructors  of  Expr  .t  and  Bind.t. 

A  first  attempt  at  elaborating  this  version  of  ExprBind  is  shown  in  Figure  5.21.  The  static  part 
of  ExprBind  is  the  same  as  it  was  before,  so  the  definitions  of  Static  and  CSS  remain  unchanged 
from  their  definitions  in  Figures  5.17  and  5.18.  The  only  change  here  is  that  the  definitions  of  Expr 
and  Bind  are  sealed  with  opaque  signatures.  This  is  problematic  because  it  means  that  the  body 
of  the  recursive  module  does  not  match  the  transparent  declared  signature  5EXPR_BIND(^'*'^'*'i^)- 
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structure  ExprBind  =  rec  (X 
struct 


-5EXPR_BIND(Static)) 


structure  Expr  :>  sig  type  t  =  Static. Expr.t 
(*  same  as  in  Figure  5.20  *)  TTT 


end  = 


struct 


end 


structure  Bind  :>  sig  type  t  |=  Static. Bind. t 
struct  ...  (*  same  as  in  Figure  5.20  *)  ... 

end 


end  = 


end 


Figure  5.22:  Elaboration  of  Expr  and  Bind  With  Sealing:  Second  Try 


signature  CSS  =  sig 

structure  Expr  :  sig  type  t  =  C  end 
structure  Bind  :  sig  type  t  =  D  end 
end 

structure  Static  :>  CSS  =  ... 

structure  ExprBind  =  rec  (X  :  -5EXPR_BIND(^'*'^'*'i^)^ 
struct 

structure  Expr  :>  sig  type  t  =  Static. Expr.t  ...  end  = 
struct  type  t  =  C  ...  end 

structure  Bind  :>  sig  type  t  =  Static. Bind. t  ...  end  = 
struct  type  t  =  D  ...  end 

end 

Figure  5.23:  Problematic  Elaboration  of  Modified  ExprBind  Example 


Figure  5.22  shows  how  the  elaborator  can  address  this  issue  by  modifying  the  sealing  signatures 
so  that  they  expose  the  equivalence  of  their  t  components  with  Static .  Expr .  t  and  Static .  Bind .  t, 
respectively.  This  technique  is  similar  to  the  one  used  to  transform  datatype  definitions  in  the 
recursive  module  body  (cf.  Figure  5.20).  Here,  however,  it  results  in  a  loss  of  data  abstraction.  In 
particular,  the  implementation  of  Bind  in  Figure  5.22  is  able  to  observe  that  Expr.t  is  equivalent 
to  Static. Expr.t,  whose  data  constructors  are  exposed  in  the  signature  CSS. 

In  the  case  of  ExprBind,  it  turns  out  that  this  loss  of  data  abstraction  is  actually  irrelevant. 
The  data  constructors  of  Expr.t  are  not  visible  in  the  signature  of  Expr  or  X.Expr,  only  in  the 
signature  of  Static  .Expr.  Since  Static  is  an  internal,  elaborator-generated  module  variable  name, 
the  implementation  of  Bind  has  no  way  of  projecting  from  Static  directly.  Consequently,  while 
Bind  gets  to  “know”  that  Expr.t  is  implemented  as  a  datatype,  it  has  no  way  of  exploiting  this 
knowledge.  Thus,  for  all  intents  and  purposes,  Expr.t  is  an  abstract  type.  (Similarly,  as  far  as 
Expr  is  concerned,  Bind.t  is  effectively  abstract  as  well.) 

Unfortunately,  the  elaboration  approach  of  Figure  5.22  only  succeeds  in  enforcing  data  abstrac¬ 
tion  boundaries  between  Expr  and  Bind  because  Expr.t  and  Bind.t  are  implemented  by  datatype 
definitions.  To  illustrate  this  point,  let  us  consider  hypothetically  how  the  elaboration  of  ExprBind 
would  differ  if  Expr .  t  and  Bind .  t  were  implemented  internally  by  the  transparent  type  bindings 
type  t  =  C  and  type  t  =  D,  respectively,  instead  of  by  datatype  bindings.  Figure  5.23  illus¬ 
trates  how  the  closed  static  signature  and  the  elaborated  recursive  module  body  would  change 
accordingly.  (Note  that,  in  order  to  obey  the  dynamic-on-static  restriction,  it  must  be  the  case 


5.4.  A  NEW  APPROACH 


115 


metasig 


structure  Expr  ; 

:  {public  = 

sig 

type 

t 

end. 

private  = 

sig 

type 

t 

=  C 

end} 

structure  Bind  ; 

:  {public  = 

sig 

type 

t 

end, 

private  = 

sig 

type 

t 

=  D 

end} 

end 

Figure  5.24:  Meta-signature  for  Modified  ExprBind 


that  neither  C  nor  D  refers  to  the  recursive  variable  X.) 

The  problem  with  this  elaboration  is  that  the  signature  CSS  reveals  the  identities  of  Expr.t 
and  Bind.t  to  the  implementations  of  both  modules.  In  order  for  data  abstraction  to  be  enforced, 
Expr  should  not  be  able  to  see  how  Static. Bind.t  is  defined,  nor  should  Bind  be  able  to  see  how 
Static. Expr.t  is  defined.  On  the  other  hand,  in  order  to  avoid  double  vision,  the  implementation 
of  Expr  needs  to  know  that  Static. Expr.t  is  equivalent  to  C,  and  the  implementation  of  Bind 
needs  to  know  that  Static. Bind.t  is  equivalent  to  D. 

What  this  tells  us  is  that  the  implementations  of  Expr  and  Bind  really  ought  to  be  typechecked 
under  different  typing  contexts.  In  other  words,  the  elaborator  needs  to  be  able  to  actively  change 
the  signature  with  which  Static  is  bound  in  the  typing  context,  depending  on  what  part  of  the 
recursive  module  body  it  is  currently  elaborating.  This  kind  of  “context  switching”  is  not  supported 
directly  by  the  IL  type  system,  so  the  elaboration  algorithm  must  implement  it  in  some  ad  hoc  way. 

To  implement  context  switching,  my  elaboration  algorithm  employs  a  novel  mechanism  called  a 
“meta-signature.”  Meta-signatures  are  a  superclass  of  ordinary  IL  signatures  in  which  the  specifi¬ 
cations  of  submodule  components  are  allowed  to  provide  both  a  “public”  and  a  “private”  signature. 
The  purpose  of  meta-signatures  is  to  encapsulate  the  type  information  that  is  known  at  different 
points  during  the  typechecking  of  a  recursive  module. 

For  example,  Figure  5.24  shows  a  meta-signature  describing  the  knowledge  of  type  information 
within  the  ExprBind  module.  In  this  meta-signature,  the  public  signatures  of  Expr  and  Bind 
indicate  what  is  publicly  known  about  their  type  components,  whereas  the  private  signatures  of 
Expr  and  Bind  indicate  what  is  privately  known  within  the  modules  themselves.  Note  that  the 
closed  static  signature  CSS  of  ExprBind  is  obtainable  from  its  meta-signature  by  ignoring  the  public 
signatures  and  just  looking  at  the  private  ones. 

The  purpose  of  ExprBind’s  meta-signature  is  to  tell  the  elaborator  how  the  signature  of  Static 
should  change  at  different  points  during  the  typechecking  of  ExprBind.  When  elaborating  the 
implementation  of  Expr,  the  meta-signature  indicates  that  the  signature  of  Static  should  use  the 
private  signature  for  Expr  and  the  public  signature  for  Bind.  When  elaborating  the  implementation 
of  Bind,  the  private  and  public  signatures  are  reversed. 

Although  the  ExprBind  example  does  not  illustrate  it,  the  meta-signature  approach  also  allows 
for  proper  treatment  of  data  abstraction  in  the  presence  of  nested  sealing.  For  example,  suppose 
that  Expr  contained  a  sealed  substructure  Sub  providing  an  abstract  type  component  u  implemented 
internally  as  int.  This  would  be  reflected  in  the  meta-signature  of  ExprBind  by  having  the  private 
signature  of  Expr  be  itself  a  meta-signature: 
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metasig 

type  t  =  C 

structure  Sub  :  {public  =  sig  type  u  end, 

private  =  sig  type  u  =  int  end} 

end 

Correspondingly,  during  the  typechecking  of  Expr.Sub,  the  signature  of  Static.Expr  would  be 

sig 

type  t  =  C 

structure  Sub  :  sig  type  u  =  int  end 
end 

whereas  during  the  typechecking  of  Expr  outside  of  Sub,  the  signature  of  Static.Expr  would  be 


sig 

type  t  =  C 

structure  Sub  :  sig  type  u  end 
end 

This  ensures  that  the  identity  of  Static . Expr . t  is  known  to  all  of  Expr,  but  the  identity  of 
Static .  Expr .  Sub . u  is  only  known  to  Expr .  Sub. 

Finally,  it  should  be  understood  that  meta-signatures  are  purely  an  elaboration  mechanism.  The 
elaborator  uses  them,  as  part  of  typechecking,  to  ensure  that  Expr  and  Bind  respect  each  other’s 
abstraction  boundaries.  Once  that  is  verified,  the  elaborator  throws  away  the  meta-signature  and 
translates  ExprBind  precisely  as  shown  in  Figure  5.23.  Thus,  the  meta-signature  technique  does 
not  require  any  extensions  to  the  IL  type  system. 


Chapter  6 

Type-Theoretic  Extensions  for 
Recursive  Modules 


In  this  chapter,  I  extend  my  module  type  system  of  Chapters  3  and  4  with  support  for  recursive  type 
constructors,  recursively  dependent  signatures,  and  recursive  modules.  The  type  system  resulting 
from  these  extensions  will  serve  as  the  basis  of  the  internal  language  (IL)  of  the  new  ML  dialect 
presented  in  Chapter  8. 

As  explained  in  Chapter  5,  all  of  the  new  recursive  constructs  are  restricted  in  various  ways, 
so  that  their  inclusion  in  the  IL  does  not  significantly  complicate  typechecking.  Recursive  type 
constructors  are  iso-recursive,  meaning  that  the  type  system  requires  the  use  of  explicit  coercions 
to  mediate  between  a  recursive  type  and  its  unfolding.  Recursively  dependent  signatures  must  obey 
a  dynamic-on-static  restriction,  prohibiting  recursive  dependencies  from  within  the  specifications 
of  type  components.  Recursive  modules  are  required  syntactically  to  have  transparent  declared 
signatures  in  order  to  avoid  the  double  vision  problem.  As  a  result,  none  of  the  extensions  presented 
in  this  chapter  poses  any  major  technical  difficulties.  Sections  6.1  through  6.4  present  the  extensions 
to  the  languages  of  type  constructors,  terms,  signatures,  and  modules,  in  that  order. 

There  are  a  few  subtleties,  however,  that  may  be  of  general  interest.  One  point  of  note  is 
the  subtyping  rule  for  recursively  dependent  signatures,  which  relies  on  singleton  signatures  in 
an  unexpected  way.  Another  is  that,  in  the  presence  of  both  singleton  kinds  and  recursive  type 
constructors  of  higher  kind,  there  exist  recursive  types — or,  more  precisely,  projections  from  recur¬ 
sive  type  constructors — whose  expansions  are  not  well-formed  under  the  iso-recursive  form  of  type 
equivalence.  To  address  this  issue,  I  identify  a  simple  restriction  on  the  kind  of  a  recursive  type 
constructor,  which  guarantees  that  its  expansion  will  be  well-formed.  While  this  is  not  the  weakest 
restriction  possible,  it  is  easy  to  explain  and  general  enough  to  support  the  elaboration  of  all  the 
recursive  module  examples  from  Chapter  5. 


6.1  Constructor-Language  Extensions 

Figure  6.1  shows  the  extensions  to  the  syntax  of  the  constructor  language  from  Chapter  3,  and 
Figure  6.2  shows  the  well-formedness  and  equivalence  rules  for  the  new  type  constructors.  The 
recursive  type  constructor  frcc.K.C  is  iso-recursive.  This  means  that  ^a:K.C  is  not  equivalent 
to  its  fixed-point  expansion  C[/xa;K.C/a].  In  addition,  two  recursive  constructors  ^a;Ki.Ci  and 
^q;:K2.C2  are  only  equivalent  if  the  Kj  are  equivalent  and  the  C*  are  equivalent. 

In  order  to  coerce  between  a  recursive  constructor  and  its  expansion,  I  will  introduce  in  Sec- 
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Type  Constructors  C,D  ::=  •••  |  fj,a:K.C 

Base  Types  b  ::=  •  •  •  |  Ci  C2  |  maybe(C) 

Figure  6.1;  Extensions  to  Type  Constructor  Syntax 


Well-formed  constructors:  A  h  C  :  K 


A,a:K  h  C  ;  K 
A  h  iia:K.C  :  K 


(105) 


A  h  C'  :  T  A  h  C" 


A  h  C'- 


■  C"  :  T 


(106) 


A  h  C  :  T 


A  h  maybe(C)  :  T 


(107) 


Constructor  equivalence:  A  h  Ci  =  C2  :  K 


A  h  Ki  =  K2  A,  a:Ki  h  Ci  =  C2  :  K 


A  h  paiKi.Ci  =  ^a:K2.C2  :  Ki 


-  (108) 


A  h  C'l  =  C'2  :  T  Ah  C'l  =  C^'  :  T 
A  h  C'l  C'l  =  C^  C^'  :  T 


(109) 


A  h  Cl  =  C2  :  T 


A  h  maybe(Ci)  =  maybe(C2)  :  T 


(110) 


Figure  6.2;  Inference  Rules  for  Type  Constructors 


tion  6.2  explicit  foldc  and  unfoldc  coercion  functions.  The  “coercion”  base  type  Ci  C2  describes 
the  types  of  these  functions.  For  instance,  if  we  were  to  add  sum  types  to  the  language,  the  type 
of  integer  lists  could  be  represented  as  D  =  |Ua;T.(unit  +  int  x  a).  In  this  case,  foldo  would  have 
type  (unit  +  int  x  D)  ~^D,  and  unfoldo  would  have  type  D-w  (unit  +  int  x  D). 

This  example  shows  how  foldo  and  unfoIdD  coerce  between  a  recursive  type  and  its  expansion, 
but  what  about  a  general  recursive  constructor  of  higher  kind?  There  is  no  way  for  a  term-level 
coercion  to  witness  the  conversion  of  D  =  p,a:K.C  to/from  C[D/a]  directly  if  K  7^  T.  However, 
what  fold  and  unfold  can  witness  is  the  conversion  of  T{D}  to/from  T{C[D/q;]},  where  £  is  some 
elimination  context  that  drives  K  down  to  T.  For  instance,  if  K  =  T  x  T,  in  which  case  D  defines 
a  pair  of  mutually  recursive  types,  then  we  can  fold  or  unfold  at  either  ttiD  or  7r2D.  If  K  =  T  ^  T, 
in  which  case  D  is  a  polymorphic  recursive  type,  then  we  can  fold  or  unfold  at  any  instantiation  of 
D,  i.e.,  at  D(C')  for  any  type  C'  (of  kind  T).  The  typing  of  foldc  and  unfoldc  will  be  studied  in 
Section  6.2. 

While  it  is  not  necessary  to  distinguish  the  type  of  coercion  functions  from  the  arrow  type  of 
ordinary  functions,  there  is  a  practical  benefit  in  doing  so.  If  values  of  a  recursive  type  C  are 
represented  in  a  compiler  in  the  same  way  as  values  of  C’s  expansion,  applications  of  foldc  and 
unfoldc  may  be  erased  during  code  generation  because  they  will  have  no  run-time  effect.  Since 
foldc  and  unfoldc  are  the  only  closed  values  of  coercion  type,  applications  of  all  values  of  coercion 
type — including  variables  or,  more  generally,  paths — may  be  erased  during  code  generation  as  well. 

Vanderwaart  et  al.  [79]  have  shown  that  coercion  types  thus  provide  a  type-preserving  way  of 
making  datatype  constructor  and  destructor  applications  more  efficient.  The  issue  is  as  follows.  In 
a  type-preserving  compiler  for  ML,  since  datatype’s  are  opaque,  a  call  to  a  datatype  constructor 
defined  in  a  separately  compiled  module  cannot  safely  be  inlined  because  it  is  not  known  what 
recursive  type  is  used  to  implement  the  datatype  (there  is  more  than  one  possibility).  However, 
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Base  type  well-formedness:  A  h  6  ok 


AhCi^T  AhC2^T  A  h  C  ^  T 

A  h  Cl  C2  ok  Ah  maybe(C)  ok 


Principal  kind  synthesis:  A  h  C  K 


A  h  K  kind  A,  a:K  h  C  ^  K 
A  h  /ioiK.C  5k(mck-K.C) 

Figure  6.3;  Extensions  to  Kind  Synthesis 


Recursive  Type  Paths  Q  ::=  £’{^a:K.C} 
Constructor  Paths  P  ::=  •  •  •  |  Q 


Natural  kind  extraction:  A  h  P  |  K 

A  h  fia:K.C  T  K 

Algorithmic  path  equivalence:  A  h  Pi  >  P2  TK 

A  h  /iccKi.Ci  >  fia:K.2-C2  T  Ki  if  A  h  Ki  K2  and  A,  q;;Ki  h  Ci  C2  ;  Ki 

A  h  C'l  ^  C'/  ^  C^  C"  T  T  if  A  h  c;  ^  C'2  :  T  and  A  h  C”  ^  C'  :  T 

A  h  maybe(Ci)  ^  maybe(C2)  T  T  if  A  h  Ci  C2  :  T 

Figure  6.4:  Extensions  to  Constructor  Equivalence  Algorithm 


if  the  datatype’s  constructor  and  destructor  have  coercion  type,  then  the  compiler  may  eliminate 
all  calls  to  them  during  code  generation.  This  saves  datatype  constructor  and  destructor  applica¬ 
tions  from  incurring  the  overhead  of  a  function  call.  My  language  definition  in  Chapter  9  adopts 
Vanderwaart  et  a/.’s  approach  in  its  interpretation  of  datatype’s. 

The  base  type  maybe(C)  describes  memory  locations  that  may  or  may  not  contain  a  value 
of  type  C.  This  is  the  type  analogue  of  the  signature  maybe(S),  whose  utility  was  discussed  in 
Section  5.2.4,  and  which  will  be  formally  added  to  the  language  in  Section  6.3.  The  type  maybe(C) 
is  needed  so  that  we  can  phase-split  the  signature  maybe(S)  into  the  core  language. 

Figures  6.3  and  6.4  show  the  extensions  to  the  kind  synthesis  and  constructor  equivalence 
algorithms.  Both  extensions  are  completely  straightforward.  It  is  worth  noting,  though,  that  the 
recursive  type  constructor  introduces  a  new  irreducible  constructor  path  of  the  form  S{iJ,a:K.C}.  I 
call  this  a  “recursive  type  path”  and  denote  it  with  the  metavariable  Q.  While  Q  =  £{fia:K.C}  is 
potentially  a  WHNF,  it  is  not  necessarily  one.  For  example,  if  K  =  T,a:T.5{a  x  a),  then  7r2Q  will 
not  be  a  WHNF,  since  the  natural  kind  of  7r2Q  will  be  5(7riQ  x  ttiQ).  Rather,  7r2Q  will  reduce  to 
ttiQ  X  ttiQ. 

I  omit  proof  that  these  extensions  do  not  disturb  the  Stone-Harper  meta-theory,  but  I  have 
verified  as  much  on  paper.  The  proof  is  easy,  primarily  because  we  have  not  made  any  changes 
to  the  kind  structure.  The  only  interesting  aspect  of  the  extension  is  the  //-constructor.  The 
iso-recursive  nature  of  //-equivalence  makes  the  extension  tantamount  to  adding  an  infinite  set  of 
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Values  V  :;=  •  •  •  |  foldc  |  unfoldc  |  foldc((u)) 
Terms  e  :;=  vi{{v2}}  |  fetch(u)  |  rec(x;C.e) 


ei((e2)) 

fetch  (e) 


=  let  xi  =  ei  in  let  X2  =  62  in  xi((x2)) 
let  X  =  e  in  fetch (x) 


Figure  6.5:  Extensions  to  Term  Syntax 


expand(Q)  =  £{C[ixa:K.C/a\},  where  Q  =  £’{/ua:K.C} 


Well-formed  terms:  T  h  e  :  C 


ri-C  =  Q:T  ThQ  expands  ri-C  =  Q:T  ThQ  expands 

r  h  foldc  :  expand(Q)  Q  T  h  unfoldc  :  Q  expand(Q) 

r  h  u  :  C'  C  r  h  uV  C'  rhv.  maybe(C)  r,x:maybe(C)  h  e  :  C 

r  h  v{{v'))  :  C  r  h  fetch(u)  :  C  T  h  rec(x  :  C.  e)  :  C 

Figure  6.6;  New  Inference  Rules  for  Terms 


primitive  constants  hk  to  the  language,  where  /xk  has  kind  (K  ^  K)  — >  K,  and  is  equivalent 

to  /xk(D)  if  and  only  if  C  is  equivalent  to  D  at  K  — >  K.  Extending  the  language  with  constructor 
constants  is  not  problematic — they  behave  just  like  variables.  Given  such  an  extension,  ^uaiK.C 
may  be  viewed  as  a  more  concise  way  of  writing  ^K(Aa:K.C). 


6.2  Term-Language  Extensions 

Eigure  6.5  shows  the  extensions  to  the  syntax  of  terms.  New  term  forms  include  the  foldc 
unfoldc  coercion  values  and  the  coercion  application  vi{{v2))-  The  application  of  foldc  to  a  value 
is  also  considered  a  value — in  fact,  foldc ((u))  is  the  canonical  form  inhabiting  recursive  types  Q. 
The  terms  fetch (u)  and  rec(x  :  C.  e)  are  the  term  analogues  of  the  module  constructs  fetch (M)  and 
rec(X  :  S.  M),  which  will  be  introduced  in  Section  6.4.  The  former  dereferences  the  memory  location 
represented  by  v,  raising  a  (run-time)  error  if  x’s  contents  are  undehned;  the  latter  allocates  a  fresh 
location  x  of  type  maybe(C),  evaluates  e  to  a  value  v,  and  then  backpatches  x  with  v. 

Figure  6.6  gives  the  typing  rules  for  these  new  term  constructs.  Rules  113-115  are  straightfor¬ 
ward.  Rules  111  and  112  for  the  foldc  and  unfoldc  values  make  use  of  a  new  macro,  expand(Q),  and 
a  new  judgment,  A  h  Q  expands.  First,  expand(Q)  is  the  constructor  produced  by  replacing  Q’s 
head,  which  has  the  form  ^a:K.C,  with  its  hxed-point  expansion  C[/xq;:K.C/q;].  If  C  is  equivalent 
to  a  recursive  type  path  Q,  then  foldc  will  be  a  coercion  function  from  expand(Q)  to  Q,  and  unfoldc 
will  coerce  in  the  opposite  direction. 

The  judgment  A  h  Q  expands,  invoked  in  the  second  premise  of  Rules  111  and  112,  is  dehned  in 
Figure  6.7.  The  purpose  of  this  premise  is  to  ensure  (1)  that  foldc  and  unfoldc  have  unique  types, 
and  (2)  that  their  types  are  well-formed.  I  will  demonstrate  first  how  both  of  these  conditions  may 
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Singleton-Free  Kinds  k,i  ::=  1  |  T  |  /ci  x  /c2  |  fei  — > /c2 

Expandable  Kinds  IC,C  ::=  IC  |  T  |  Sa:/Ci./C2  |  Ila:ki.lC2 


Expandable  recursive  types:  A  h  Q  expands 


AhQ:T  AFQTT  Q  =  £{fia:}C.C} 
A  h  Q  expands 

Eigure  6.7;  Expandable  Kinds  and  Types 


Type  synthesis:  T  h  e  C 


rhC:T  FhC^Q  ThQ  expands  ThCiT  ThC^Q  ThQ  expands 
r  h  foldc  expand(Q)  Q  T  h  unfoldc  Q  expand(Q) 

Ehn^C'-^C  ri-r;'<;=C'  Thn^  maybe(C)  T  h  C  :  T  T,  x:maybe(C)  h  e  C 
T  h  v{{v'))  C  T  h  fetch (v)  ^  C  T  h  rec(x:C.e)  ^  C 

Eigure  6.8;  Extensions  to  Type  Synthesis 


fail  in  the  absence  of  this  premise,  and  second  how  the  definition  of  A  h  Q  expands  in  Eigure  6.7 
ensures  that  they  do  not. 

Suppose  that  the  second  premise  of  Rules  111  and  112  were  omitted.  The  first  problem  is 
that,  by  singleton  reasoning,  every  type  C  is  equivalent  to  a  recursive  type  Q,  namely  the  type 
Q  =  fra:5{C).C.  In  this  case,  expand(Q)  is  precisely  C,  so  foldc  and  unfoldc  could  always  be  given 
the  type  C~^C.  Of  course,  C  might  be  equivalent  to  a  “real”  recursive  type,  such  as  /U/3;T.D,  in 
which  case  foldc  could  also  be  given  the  type  D[C//3]  C.  Since  C  is  not  equivalent  to  D[C//3],  we 
would  therefore  lose  unicity  of  types. 

The  second  problem  is  that  the  well-formedness  of  Q  does  not  imply  the  well-formedness  of 
expand(Q).  Eor  example,  consider  the  following  set  of  contrived,  yet  illustrative,  definitions; 

K  =  S/3;T.5(/3)^T 

C  *=  ^a;K. (unit,  AQ;';S(unit). unit) 

Q  =  (7r2C)(7riC) 

Note  that  Q  has  the  form  T{C},  where  £  =  (7r2(«))(7riC).  As  C  has  kind  K,  it  is  clear  that  Q  is 
a  well-formed  type.  However,  expand(Q)  =  (7r2(expand(C)))(7riC)  is  not  well-formed.  Specihcally, 
7r2(expand(C))  has  arrow  kind  S('7ri(expand(C)))  — >  T,  whose  argument  kind  is  not  matched  by  ttiC. 
This  problem  does  not  arise  under  an  equi-recursive  account  of  constructor  equivalence — in  that 
setting,  C  would  be  considered  equivalent  to  expand(C),  so  expand(Q)  would  be  well-formed.  Of 
course,  in  an  equi-recursive  setting,  foldc  and  unfoldc  are  not  necessary  in  the  first  place. 

The  judgment,  A  h  Q  expands,  addresses  the  unicity-of-types  problem  by  requiring  Q  to  be  in 
weak  head  normal  form.  Eormally,  this  means  that  Q  is  a  type  path  rooted  at  a  ;U-constructor  and 
its  natural  kind  is  T.  This  restriction  prevents  one  from  passing  off  any  type  as  a  recursive  type. 
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since  fj,a:5(C).C  is  not  in  WHNF  (its  natural  kind  is  5(C),  so  it  reduces  to  C).  Only  types  whose 
WHNF’s  have  the  form  Q  may  be  used  as  the  parameter  to  fold  and  unfold.  As  this  marks  the 
hrst  intrusion  of  natural  kind  extraction  into  the  core  language  type  system,  it  is  important  to  show 
that  natural  kind  extraction  for  recursive  type  paths  obeys  weakening  and  substitution.  In  fact, 
this  turns  out  to  be  trivial,  since  the  procedure  for  extracting  the  natural  kind  of  a  recursive  type 
path  never  even  inspects  the  typing  context!  Only  paths  rooted  at  variables  require  inspection  of 
the  typing  context. 

Proposition  6.2.1  (Natural  Kind  Extraction  for  Recursive  Type  Paths) 

If  A  h  Q  I  K,  then  A'  h  yQ  |  yK  for  any  A'  and  7. 

As  for  the  second  problem,  the  most  obvious  solution  would  be  for  the  judgment  A  h  Q  expands 
to  require  that  A  h  expand (Q)  :  T.  This  is  clearly  a  necessary  condition.  While  I  conjecture  that 
it  is  also  a  sufficient  one,  I  have  been  unable  to  prove  that  the  resulting  type  checking  algorithm 
(Figure  6.8)  is  complete.  In  particular,  the  completeness  proof  relies  on  the  property,  stated  below  in 
Theorem  6.2.5,  that  if  Q  and  are  equivalent  WHNF  types  and  A  h  Q  expands,  then  expand(Q') 
is  well- formed  as  well  and  equivalent  to  expand (Q).  In  order  to  prove  this  theorem,  I  impose  a 
stronger  condition  on  A  h  Q  expands  than  the  well-formedness  of  expand (Q) — I  require  that  Q  be 
syntactically  expandable. 

Figure  6.7  dehnes  a  recursive  type  path  Q  to  be  expandable  if  Q’s  head  has  the  form  fia:IC.C, 
where  1C  is  a  syntactically  expandable  kind.  The  definition  of  expandable  kinds  is  motivated 
conversely  by  the  desire  to  ensure  that  all  expandable  constructors  have  well-formed  expansions, 
i.e.,  that  A  h  Q  expands  implies  A  h  expand (Q)  :  T.  Toward  this  end,  the  only  restriction  placed 
on  an  expandable  kind  K,  is  that,  for  any  arrow  kind  within  1C  of  the  form  na:Ki.K2,  either  the 
result  kind  K2  must  be  transparent  or  the  argument  kind  Ki  must  be  singleton- free.  This  avoids 
precisely  the  sort  of  counterexample  given  above,  in  which  the  kind  K  of  the  /x-constructor  took 
the  form  S/3:T.S(/3)  — >T.  In  essence,  it  is  a  “monster-barring”  restriction  (cf.  Lakatos  [40,  27]). 

Intuitively,  the  reason  the  restriction  works  is  that  it  prevents  the  well-formedness  of  an  ex¬ 
pandable  type  Q  =  £{p,a:lC.C}  from  depending  on  the  fact  that  its  head  is  p,a:lC.C  as  opposed  to 
any  other  constructor  of  kind  1C.  That  is,  if  Q  is  well-formed,  then  ^{D}  will  be  well- formed  for 
any  D  that  has  kind  1C.  This  includes  expand(Q)  =  £{C[fia:lC.C/a]}. 

While  the  syntactic  restriction  on  expandable  kinds  is  more  conservative  than  absolutely  nec¬ 
essary,  it  has  the  advantage  of  being  easy  to  define  and  understand.  ^  Furthermore,  it  enables  us 
to  support  the  elaboration  of  all  the  recursive  module  examples  from  Chapter  5.  The  only  sorts  of 
recursive  modules  whose  elaboration  it  prevents  are  those  that  contain  datatype  definitions  in  the 
bodies  of  functor  bindings.  As  I  have  not  yet  seen  any  compelling  examples  of  recursive  functors, 
I  suspect  that  this  is  not  a  great  loss.  (See  Section  9.3.8  for  more  detailed  discussion  of  this  issue.) 

I  will  now  proceed  to  prove  the  critical  Theorem  6.2.5.  The  proof  relies  on  a  technical  “head 
replacement”  lemma  (Lemma  6.2.4),  whose  statement  depends  on  a  notion  of  structural  similarity 
of  kinds.  Two  kinds  are  structurally  similar  if  they  appear  identical  when  one  ignores  the  contents 
of  their  constituent  singleton  kinds.  Here  is  the  formal  definition,  followed  by  a  proposition  enu¬ 
merating  several  properties  of  structural  similarity  that  are  provable  by  straightforward  induction. 


^In  addition,  as  I  expect  in  fnture  work  to  be  able  to  eliminate  a  syntactic  condition  on  Q  altogether  and  replace 
it  with  the  minimal  requirement  that  expand(Q)  be  well-formed,  I  see  little  point  in  developing  finer,  more  complex 
approximations  of  expandability,  only  to  discard  them  in  the  near  future. 
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Definition  6.2.2  (Strnctural  Similarity  of  Kinds) 

Kinds  Ki  and  K2  are  structurally  similar  (written  Ki  K2)  if: 

•  Ki  =  K2 

•  Or,  Ki  =  S(Ci)  and  K2  =  S(C2) 

•  Or,  Ki  =  Sa:K;.K'/  and  K2  =  and  K'^  and  K”  ^  K" 

•  Or,  Ki  =  na:K;.K'/  and  K2  =  and  K;  and  K'/  K^' 

Proposition  6.2.3  (Properties  of  Structural  Similarity) 

1.  Structural  similarity  is  an  equivalence  relation. 

2.  If  Ki  ~  K2  and  Ki  is  singleton-free,  then  Ki  =  K2. 

3.  If  Ki  ~  K2  and  Ki  is  expandable,  then  K2  is  expandable. 

4.  If  Ki  ~  K2,  then  71K1  ~  72K2  for  any  71  and  72. 

5.  If  A  h  Ki  =  K2,  then  Ki  ps  K2. 

The  head  replacement  lemma  has  two  parts.  The  first  part  says  that  if  £’{P}  is  a  well- formed 
type  in  WHNF,  and  if  P  has  an  expandable  natural  kind  C,  then  we  can  replace  P  by  any  other 
path  P'  of  kind  C,  and  the  resulting  type  T{P'}  will  be  well-formed.  The  second  part  says  that 
if  Ti{Pi}  and  £2{P2}  are  algorithmically  equivalent  paths  of  kind  T,  and  the  natural  kind  of  Pi 
is  the  expandable  C,  then  we  can  replace  the  P*  by  any  other  pair  of  algorithmically  equivalent 
constructors  P(  of  kind  £,  and  the  resulting  £’j{P(}  will  be  algorithmically  equivalent  as  well.  The 
lemma  is  stated  in  a  somewhat  more  general  fashion  in  order  to  make  the  induction  go  through. 

Lemma  6.2.4  (Head  Replacement) 

1.  Suppose  A  h  P  I  T  and  A  h  P'  :  £',  where  L  k,  CJ . 

If  ^{P}  is  well-formed  in  A  and  A  h  £’{P}  t  K;  where  K  is  not  transparent, 
then  there  exists  K,'  such  that  A  h  iflP'}  :  IC  and  K  K,' . 

2.  Suppose  A  h  Pi  P2  T  ^  and  A  h  P'^  P2  T  1  where  C  C . 

If  A  h  £’i{Pi}  T2IP2}  T  K,  where  K  is  not  transparent, 

then  there  exists  K,'  such  that  A  h  (filP'^j  £’2{P2}  T  Ki'  and  K  IC'. 

Proof:  By  induction  on  the  structure  of  £  in  Part  1,  and  £i  and  £2  in  Part  2. 

I.  •  Case;  £  =  •.  Trivial. 

•  Case:  £  =  tx\£' . 

(a)  We  have  A  h  £{P}  j  Ki,  where  A  h  f'{P}  j  Sa:Ki.K2. 

(b)  By  induction,  A  h  £'{P'}  :  Sa:/C'^./C2,  where  Ki  JC'^  and  K2  ~  /C^- 

(c)  Thus,  A  h  TjP'}  :  /C^. 

•  Case:  £  =  tx2£' ■ 

(a)  We  have  A  h  T{P}  j  K2[7rif’'{P}/a],  where  A  h  £'{P}  ]  Sq;:Ki.K2. 

(b)  By  induction,  A  h  £'{P'}  :  Sa:/C'^./C2,  where  Ki  JC'^  and  K2  ~  /C^- 

(c)  Thus,  A  h  TjP'}  :  /C^[7ri£:'{P'}/a]. 

(d)  By  Proposition  6.2.3,  K2[7riT'{P}/a]  ss  /C2[7riT'{P'}/a]. 
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•  Case:  £  =  £'(0). 

(a)  We  have  A  h  i?{P}  T  K2[C/a],  where  A  h  £'{P}  ]  nQ;:Ki.K2. 

(b)  Since  <?{P}  is  well-formed  in  A,  by  Proposition  3.1.17,  A  h  C  :  Ki. 

(c)  By  induction,  A  h  £'{P'}  |  where  Ki  Ri  k'^  and  K2  ~ 

(d)  By  Proposition  6.2.3,  Ki  =  k[,  so  A  \-  C  :  k[. 

(e)  Thus,  AhT{P'}  :  /C^[C/a]. 

(f)  By  Proposition  6.2.3,  K2[C/a]  ^  JC2[C/ a]. 

2.  •  Case;  £i  =  •.  Trivial. 

•  Case:  £i  =  '/ri£’|. 

(a)  We  have  A  h  Ti{Pi}  ^  ^2{P2}  T  Ki,  where  A  h  ^  T  Sa:Ki.K2. 

(b)  By  induction,  A  h  (fJlP'^}  ^  £2{P'2]  T  'Ea\X[.X2,  where  Ki  and  K2  ~  /C^. 

(c)  Thus,  A  h  £,{P[}  ^  £2{P'2}  T  /C[. 

•  Case:  f*  =  vr2(?'. 

(a)  We  have  A  h  TUPi}  ^  ^2{P2}  T  K2[7rif({Pi}/a], 
where  A  h  (fdPi}  <->  T2{P2}  T  Sa:Ki.K2. 

(b)  By  induction,  A  h  £[{P'i}  ^  T  Sa:/C'^./C2)  where  Ki  K'l  and  K2  ~  /C2. 

(c)  Thus,  A  h  TUP' }  T2{P'2}  T  /C' [vriTUPil/a]- 

(d)  By  Proposition  6.2.3,  K2[7riT({Pi}/a]  k,  /CU'^1‘^i{Pi}/q^]- 

•  Case:  £i  =  £[{Ci). 

(a)  We  have  A  h  Ti{Pi}  ^  T2{P2}  T  K2[Ci/a], 

where  A  h  T^Pi}  ^  £2(^2}  T  na:Ki.K2  and  A  h  Ci  C2  :  Ki. 

(b)  By  induction,  A  h  £[{P'i}  ^  T^PU  T  where  Ki  k'l  and  K2  ~  /C^- 

(c)  By  Proposition  6.2.3,  Ki  =  /c^,  so  A  h  Ci  C2  :  k'l- 

(d)  Thus,  A  h  Ti{P'i}  ^  TajP'a}  T  /CUCi/a]. 

(e)  By  Proposition  6.2.3,  K2[Ci/a]  /C^lCi/a]- 


Theorem  6.2.5  (Equivalent  Expandable  Types  Have  Equivalent  Expansions) 

If  A  h  Q  =  Q'  :  T  and  A  h  Q  expands  and  A  h  Q'  |  T, 
then  A  h  Q'  expands  and  A  h  expand(Q)  =  expand(Q')  :  T. 

Proof: 

1.  Let  Q  =  £{fia:K.C}  and  Q'  =  £’'{^a:K'.C'}. 

2.  By  the  equivalence  algorithm,  A  h  iJ,a:K.C  =  /ra:K'.C'  ;  K, 

A  h  K  =  K'  and  A,  a;K  h  C  =  C'  :  K. 

3.  By  functionality,  A  h  C[iia\H.C / a]  =  C'[^Q;:K'.C'/a]  :  K. 

4.  Since  A  h  Q  expands,  K  is  expandable.  By  Proposition  6.2.3,  K'  is  expandable  and  K  ~  K'. 

5.  Thus,  A  h  Q'  expands. 

6.  Let  A'  =  A,  (3-.K.  We  have  A'  h  /?  :  K,  A'  h  ixw.K.C  j  K  and  A'  h  ^a:K'.C'  T  K'. 
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7.  By  Part  1  of  Lemma  6.2.4,  A'  h  8{f3}  :  T  and  A'  h  £'{(3}  :  T. 

8.  By  the  equivalence  algorithm,  A'  h  Q  ^  Q'  |  T,  A'  h  /3  /?  |  K, 

and  A'  h  |Ua:K.C  /ra;K'.C'  |  K. 

9.  By  Part  2  of  Lemma  6.2.4,  A'  h  £{(5}  ^  ^'{(^}  T  T. 

10.  By  soundness  of  the  equivalence  algorithm.  A'  h  £{j3}  =  £'{(3}  :  T. 

11.  By  functionality,  A  h  £{C[iia:E..C / a]}  =  £’'{C'[^a:K'.C'/a]}  :  T. 

12.  In  other  words,  A  h  expand(Q)  =  expand(Q')  :  T. 


Corollary  6.2.6  (Well-Formed  Expandable  Types  Have  Well-Formed  Expansions) 

If  A  h  Q  expands,  then  A  h  expand(Q)  ;  T. 

Proof:  By  Theorem  6.2.5,  Reflexivity,  and  Validity.  ■ 

Given  Theorem  6.2.5,  it  is  easy  to  prove  that  the  type  synthesis  algorithm,  the  new  cases  of 
which  are  shown  in  Figure  6.8,  is  complete. 

Proposition  3.2.6  (Completeness  of  Type  Checking) 

If  r  h  e  :  C,  then  T  h  e  C. 

Proof:  Interesting  new  cases:  Rules  111  and  112.  I  will  show  the  former,  the  latter  is  analogous. 

1.  We  have  T  h  foldc  :  expand(C)  C,  where  T  h  C  =  Q  :  T  and  T  h  Q  expands. 

2.  By  Proposition  3.1.19,  P  h  C  P  and  P  h  C  =  P  :  T. 

3.  Thus,  rhQ  =  P:T,  ThQTTandrhPtT. 

4.  By  the  equivalence  algorithm,  ThQ^PIT,  soP  must  have  the  form  Q'. 

5.  By  Theorem  6.2.5,  T  h  Q'  expands  and  T  h  expand(Q)  =  expand(Q')  :  T. 

6.  Thus,  T  h  foldc  ^  expand (Q')  Q',  and  T  h  expand (Q')  Q'  =  expand (Q)  Q  :  T. 


In  order  to  formalize  the  evaluation  of  the  recursive  term  construct  rec(a; :  C.  e),  it  is  useful  to 
generalize  the  structural  operational  semantics  of  Section  3.2.5  to  an  abstract  machine  semantics 
with  an  explicit  store  and  control  stack. ^  Figure  6.9  illustrates  how  this  is  done. 

Machine  stores  u)  are  mappings  from  a  finite  set  of  variables  x  (representing  memory  locations) 
to  the  contents  stored  at  those  locations.  The  contents  of  location  x,  written  uj{x),  is  either  a  value 
(v)  or  undefined  junk  (?).  By  uj[x  !—>•••]  (resp.  uj[x  :=  •  •  •])  I  denote  the  result  of  extending  (resp. 
updating)  the  store  to  with  the  binding  of  x  to  •  •  •.  The  empty  store  is  denoted  e. 

A  machine  state  £l  is  either  the  error  state  (Error)  or  a  normal  state  of  the  form  (t(;;C;e), 
where  to  is  the  current  store,  C  is  the  current  continuation,  and  e  is  the  term  currently  being 
evaluated.  A  continuation  C  consists  of  a  stack  of  continuation  frames  T.  There  are  only  two  forms 
of  continuation  frames  in  the  language;  one  is  pushed  onto  the  continuation  stack  when  evaluating 
a  let  binding,  the  other  when  evaluating  the  body  of  a  recursive  term. 

^An  abstract  machine  semantics  also  makes  it  easier  to  formalize  exception  handling  in  the  full  IL  of  Chapter  8. 
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Machine  Stores  lo 

Machine  States  Q 

Continuations  C 

Continuation  Frames  J- 


(u;;C;e)  |  Error 
•  \CoH 

let  X  =  •  in  e  I  rec(x  :  C.  •) 


Small-step  semantics:  fl  Q' 


{uj;C;  let  x  =  e'  in  e)  i— >  (u;;  C  o  let  x  =  •  in  e;  e')  (w;  C  o  let  x  =  •  in  e;v)  e[v/x]) 

X  ^  dom(t(;)  x  G  dom(t(;) 

{(jj;  C;  rec(x  :  C.  e))  {uj[x  ?];  C  o  rec(x  :  C.  •);  e)  (w;  C  o  rec(x  :  C.  •);  v)  {uj[x  :=  x];  C;  v) 

(tx;C;  unfoldc((foldD((x)))))  {uj;C;v) 

X  €  dom(u;)  cx(x)  =  v  x  G  dom(t(;)  a;(x)  =  ? 

(w; C; fetch(x))  (iv;C;v)  (tx; C; fetch (x))  Error 

For  all  other  rules  of  the  form  e  e'  from  Figure  3.14,  we  now  have: 

(tx;  C;  e)  (w;  C;  e') 

Figure  6.9;  Abstract  Machine  Semantics  With  Explicit  Store  and  Control  Stack 


Well-formed  continuations:  F  h  C  ;  C  cont 


_  FhJ^:C^D  FhC:D  cont 

F  h  •  :  C  cont  F  h  C  o  .F  :  C  cont 


F  h  C  :  D  cont  F  h  D  =  C  :  T 
F  h  C  :  C  cont 


Well- formed  continuation  frames:  F  h  .F  :  Ci  C2 

F,x:Ci  h  e  :  C2  x:maybe(C)  G  F 

F  h  let  X  =  •  in  e  :  Cl  ^  C2  F  h  rec(x :  C.  •)  :  C  C 

Figure  6.10:  Well-Formed  Continuations 


The  definition  of  well-formed  machine  state,  given  below  in  Definition  6.2.9,  relies  naturally  on 
a  notion  of  well-formed  continuation  and  well-formed  machine  store.  The  former  is  formalized  in 
Figure  6.10  in  a  fairly  typical  way.^  The  latter  depends  in  turn  on  a  notion  of  “run-time”  context, 
which  is  a  context  that  only  binds  variables  at  types  classifying  locations  in  the  store.  Run-time 
contexts  and  well-formed  stores  are  formalized  as  follows: 

Definition  6.2.7  (Run-Time  Contexts) 

A  context  F  is  run-time  if  the  only  bindings  in  F  have  the  form  x;maybe(C). 

®N.B.  The  only  oddity  perhaps  is  the  premise  a;:maybe(C)  €  F  in  the  recursive  term  frame  rule,  which  is  needed  in 
order  to  prove  progress  for  the  recursive  backpatching  step.  The  important  point  here  is  that  the  frame  rec(® :  C.  •) 
does  not  bind  the  variable  x.  When  this  frame  comes  into  existence,  x  refers  to  a  location  that  has  been  created  in 
the  machine  store,  and  thus  it  must  be  bound  in  the  context  F. 
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Definition  6.2.8  (Well-Formed  Machine  Stores) 

A  machine  store  to  is  well-formed,  denoted  F  h  cj,  if: 

1.  r  is  run-time  and  dom(t(;)  =  dom(r) 

2.  Vx:maybe(C)  G  F.  either  uj{x)  =  ?  or  =  v,  where  F  h  :  C 

We  can  now  define  a  notion  of  well-formed  machine  state,  which  requires  that  the  type  of  the  term 
currently  being  evaluated  is  the  same  as  the  type  that  the  current  continuation  expects: 

Definition  6.2.9  (Well-Formed  Machine  States) 

A  machine  state  Ll  is  well-formed,  denoted  F  h  if  either  =  Error  or  =  {u)',C',  e),  where: 

1.  Fhw 

2.  3C.  F  h  C  :  C  cont  and  F  h  e  :  C 

We  can  now  state  the  preservation  and  progress  theorems  leading  to  type  safety. 

Theorem  6.2.10  (Preservation) 

If  F  h  n  and  Ll  Q',  then  3  F'.  F'  h  O'. 

Definition  6.2.11  (Terminal  States) 

A  machine  state  Ll  is  terminal  if  it  has  the  form  Error  or  {uj',*-,v). 

Definition  6.2.12  (Stuck  States) 

A  machine  state  0  is  stuck  if  it  is  non-terminal  and  there  is  no  state  Ll'  such  that  fib 

Theorem  6.2.13  (Progress) 

If  F  h  n,  then  0  is  not  stuck. 

Corollary  6.2.14  (Type  Safety) 

If  0  h  e  :  C,  then  the  evaluation  of  (e;  •;  e)  never  enters  a  stuck  state. 

Lastly,  the  proof  of  progress  relies  on  the  following  extension  of  the  canonical  forms  lemma  from 
Section  3.2.5: 

Lemma  6.2.15  (Canonical  Forms) 

Suppose  that  F  is  run-time  and  F  h  u  C. 

1.  If  C  is  of  the  form  maybe(D),  then  v  is  of  the  form  x. 

2.  If  C  is  of  the  form  Ci  C2,  then  v  is  of  the  form  foldo  or  unfoldo- 

3.  If  C  is  of  the  form  Q,  then  v  is  of  the  form  foldD((^^0)- 

4.  All  other  cases  are  the  same  as  in  Lemma  3.2.8. 
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Signatures  S,R  ::=  •••  |  maybe(S)  |  pX.S 

Transparent  Signatures  S,M  ::=  •••  |  maybe(S)  |  pX.S 

Fst(maybe(S))  Fst(S) 

Fst(/9X.S)  Fst(S),  assuming  X'^  0  FV(Fst(S)) 

Smaybe(S)(C)  =  maybe(5s(C)) 

Spx.s(C)  =  p(Ss[c/x"](C)) 

Figure  6.11:  Extensions  to  Signature  Syntax  and  Related  Functions 


6.3  Signature-Language  Extensions 

Figure  6.11  shows  the  extensions  to  the  language  of  signatures  from  Chapter  4.  There  are  two 
new  signature  forms;  the  maybe(S)  signature  used  to  classify  recursive  module  variables,  and  the 
recursively  dependent  signature  pX.S.  I  will  write  p(S)  as  shorthand  for  pX.S  when  X'^  ^  FV(S), 
i.e.,  when  the  rds  is  “degenerate.” 

Figure  6.11  also  gives  the  corresponding  extensions  to  the  definitions  of  Fst(S)  and  Ss(C).  Let 
us  begin  with  maybe(S).  Extensionally  speaking,  a  module  M  of  signature  maybe(S)  is  like  a  functor 
of  signature  1  S.  There  is  only  one  thing  we  can  do  with  it — fetch  it,  which  may  raise  a  run-time 
error — ^just  as  there  is  only  one  thing  we  can  do  with  a  functor  with  unit  argument,  and  that  is 
to  apply  it  to  ().  The  analogy  is  to  a  total,  rather  than  a  partial,  functor,  because  every  fetch  (M) 
returns  the  same  module  value  with  the  same  type  components,  if  it  returns  at  all.  This  analogy 
would  suggest  that  Fst(maybe(S))  be  defined  as  l^Fst(S),  and  5maybe(s)(C)  as  maybe(5s(C())). 
The  definition  in  Eigure  6.11  takes  the  extra  step  of  reducing  Fst(maybe(S))  from  1  — >  Fst(S)  to 
Fst(S),  as  the  two  kinds  are  isomorphic. 

The  rds  construct  pX.S  describes  modules  M  of  signature  S[M/X].  The  dynamic-on-static 
restriction  (discussed  extensively  in  Chapter  5)  ensures  that  Fst(S)  may  not  refer  to  X'^  and  therefore 
that  Fst(S[M/X])  =  Fst(S).  Correspondingly,  Fst(pX.S)  is  defined  simply  as  Fst(S).  As  for  the 
singleton  signature  5px.s(C),  it  is  intended  to  describe  modules  M  of  signature  S[M/X]  whose 
static  part  Fst(M)  is  equivalent  to  C — that  is,  modules  M  of  signature  Ss[m/x](C).  This  latter 
signature  is  in  turn  equivalent  to  Sgjc/x^CC),  since  Fst(M)  is  equivalent  to  C. 

Note  that  the  definition  of  Spx.s(C)  ia  Eigure  6.11  places  5s[c/x4(C)  inside  a  degenerate  rds 
p(-).  Morally,  for  any  S,  the  signatures  S  and  p{S)  are  equivalent.  In  this  calculus,  however,  I  have 
chosen  to  distinguish  them  and  introduce  explicit  introduction  and  elimination  forms  for  rds’s  (see 
Section  6.4  below). ^  This  approach  allows  us  to  maintain  the  syntax-directed  nature  of  signature 
equivalence/subtyping,  which  simplifies  the  meta-theory.  Since  rds’s  are  only  considered  subtypes 
of  other  rds’s,  the  definition  of  SpX.s(C)  is  wrapped  in  a  degenerate  rds  in  order  to  preserve  the 
property  that  Ss(C)  is  a  subtype  of  S. 

Eigure  6.12  gives  the  well-formedness,  equivalence  and  subtyping  rules  for  the  new  signature 
constructs.  The  rules  for  maybe(S)  signatures  are  all  obvious.  As  for  rds’s,  the  well-formedness 
rule  (Rule  117)  is  precisely  the  one  given  in  Section  5.2.2  of  the  previous  chapter.  The  rds  sub¬ 
typing  and  equivalence  rules,  though,  are  rather  unusual:  what  are  singleton  signatures  doing  in 

^The  programmer  of  the  external  language  defined  in  Chapter  9  will  not  have  to  write  these  explicit  coercions 
herself — the  elaborator  infers  them  as  part  of  signature  matching. 
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Well-formed  signatures:  A  h  S  sig 


A  h  S  sig 
A  h  maybe(S)  sig 


(116) 


A,X^:Fst(S)  h  S  sig 
A  h  pX.S  sig 


(117) 


Signature  equivalence:  A  h  Si  =  S2 


A  h  Si  =  S2 

A  h  maybe(Si)  =  maybe(S2) 


(118) 


A  h  yoX.Si  sig  A  h  /9X.S2  sig 
Ah  Fst(Si)  =  Fst(S2)  A,XhFst(Si)  hSsi(X")  =Ss2(X^) 
AhpX.Si  =  pX.S2 

Signature  subtyping:  A  h  Si  <  S2 


(119) 


A  h  Si  <  S2 

A  h  maybe(Si)  <  maybe(S2) 


(120) 


A  h  pX.Si  sig  A  h  /9X.S2  sig 
Ah  Fst(Si)  <  Fst(S2)  A,XhFst(Si)  hSsi(X")  <Ss2(X") 
AhpX.Si  <pX.S2 


(121) 


Figure  6.12:  New  Inference  Rules  for  Signatures 


the  last  premise?  Wouldn’t  a  more  natural  premise  (in  the  rds  subtyping  rule,  for  instance)  be 
A,XhFst(Si)  h  Si  <  S2? 

The  problem  with  this  simpler,  more  obvious  premise  is  that  it  is  considerably  more  restrictive 
than  necessary.  For  example,  consider  the  signatures  Ri  =  pX.Si  and  R2  =  pX.S2,  where 

51  =  SY:|T|.|7riX"  X  Y^l 

52  =  SY:|T|.|Y^X7riXi 

Written  in  pseudo-ML  syntax,  these  would  correspond  to 

Ri  *=  pX.  sig  type  t  ;  val  x  :  X.t  *  t  end 
R2  =*  pX.  sig  type  t  ;  val  x  :  t  *  X.t  end 

Intuitively,  when  checking  whether  Ri  is  a  subsignature  of  R2,  t  and  X.t  should  be  treated  as 
equivalent  because  they  are  really  different  ways  of  referring  to  the  same  type  component.  However, 
the  premise  A,  X‘^:Fst(Si)  h  Si  <  S2  does  not  identify  them;  it  simply  compares  Si  and  S2  directly, 
and  in  the  above  example  Si  and  S2  are  incomparable. 

Rules  119  and  121  address  this  limitation  by  comparing  Ssi(X'’)  and  Ss2(X‘^)  instead  of  Si  and 
S2.  In  terms  of  the  example  above,  this  approach  eliminates  the  distinction  between  t  and  X.t.  For¬ 
mally,  Ri  and  R2  will  be  deemed  equivalent  since  Ssi(X'’)  =  Ss2(X'’)  =  |S(7riX'’)]  x  [vriX'’  x  ttiX'’]. 

The  new  signature  forms  introduced  in  this  section  do  not  cause  any  meta-theoretic  problems. 
Nonetheless,  since  the  subtyping  and  equivalence  rules  for  rds’s  are  so  unusual,  I  will  give  here  the 
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proofs  for  the  rds  cases  in  several  of  the  declarative  properties  from  Section  4.1.3.  I  will  omit  the 
proofs  for  the  maybe(S)  cases,  which  are  all  straightforward. 

Definition  4.1.2  (Sizes  of  Signatnres) 

size(maybe(S))  1  +  size(S) 
size(pX.S)  '=  1  +  size(S) 

Proposition  4.1.3  (Facts  About  Fst(S)  and  Ss(C)) 

1.  If  A  h  C  :  Fst(S),  then  A  h  Fst(Ss(C))  =SFst(S)(C). 

3.  If  A  h  S  sig  and  A  h  C  :  Fst(S),  then  A  h  5s (C)  sig. 

Proof:  New  case:  S  =  pX.R,  so  Fst(S)  =  Fst(R)  and  X*^  0  FV(Fst(R)). 

1.  (a)  By  definition,  Fst(Ss(C))  =  Fst(/9  (Sr[c/x-]  (C)))  =  Fst(SR[c/x<=]  (C)). 

(b)  By  induction,  A  h  Fst(SR[c/x-] (C))  =  SFst{R)[c/x-] (C). 

(c)  Since  X'^  0  FV(Fst(R)),  we  have  5Fst(R)[C/x<=](C)  =  SFst(s)(C). 

3.  (a)  By  definition,  we  need  to  show  that  A  h  p  (Sr[c/x<=]  (C))  sig. 

(b)  First,  Fst(R[C/X'^])  =  Fst(R),  so  by  assumption,  A  h  Fst(R[C/X'^])  kind. 

(c)  Second,  since  A,X'^:Fst(R)  h  R  sig  and  A  h  C  ;  Fst(R), 

(d)  By  Substitution,  A  h  R[C/X'^]  sig. 

(e)  By  induction,  A  h  5r[c/x^](C)  sig,  so  A  h  p  (Sr[c/x-](C))  sig. 


Proposition  4.1.4  (Reflexivity) 

If  A  h  S  sig,  then  A  h  S  =  S  and  A  h  S  <  S. 

Proof:  By  induction  on  size(S).  New  case:  S  =  pX.R. 

1.  By  assumption,  A,X'^:Fst(R)  h  R  sig. 

2.  By  Reflexivity,  A  h  Fst(R)  =  Fst(R). 

3.  By  Part  3  of  Proposition  4.1.3,  A,X'^:Fst(R)  h  Sr(X'^)  sig. 

4.  Since  size(SR(X‘^))  =  size(R)  <  size(S),  by  induction,  A,X'^:Fst(R)  h  5r(X'^)  =  Sr(X‘^). 

5.  Thus,  A  h  pX.R  =  pX.R. 

The  proof  of  A  h  pX.R  <  pX.R  is  similar.  ■ 

Proposition  4.1.9  (Singleton  and  Transparent  Signature  Rules) 

1.  If  A  h  S  sig  and  A  h  C  :  Fst(S),  then  A  h  5s (C)  <  S. 

2.  If  A  h  S  sig  and  A  h  C  :  Fst(S),  then  A  h  5s(C)  =  §. 

3.  If  A  h  Si  <  Sa  and  A  h  Ci  =  Ca  :  Fst(Si),  then  A  h  5si(Ci)  <  532(02). 
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Signature  phase-splitting:  S  ^  Ia:K.Cl 

S  ^  |a:K.C]  S  ^  |a:K.C| 

maybe(S)  |a:K.maybe(C)]  pX.S  ^  [a;K.C[a/X'^]] 

Figure  6.13;  New  Signature  Phase-Splitting  Rules 


Proof:  New  case:  S  =  pX.R,  S*  =  pX.Rj.  The  proof  makes  use  inductively  of  Corollary  6.3.1, 
shown  below. 

1.  (a)  Let  M' =  Sr[C/x^](C). 

(b)  Since  5s (C)  =  p  (M'),  we  need  to  show  that  A  h  p  (M')  <  pX.R. 

(c)  First,  by  Proposition  4.1.3,  A  h  Fst(M')  =SFst(R)(C). 

(d)  By  Proposition  3.1.12,  A  P5Fst(R)(C)  <  Fst(R). 

(e)  Thus,  by  Transitivity,  A  h  Fst(M')  <  Fst(R). 

(f)  Second,  by  Proposition  4.1.3  and  Reflexivity,  A,  X‘^:Fst(M')  h  Sr(X‘^)  =  Sr(X'^). 

(g)  Since  A,  X'^:Fst(M')  h  C  =  X*^  ;  Fst(M'),  by  Functionality,  A,  X'^:Fst(M')  h  M'  =  5r(X'^). 

(h)  By  induction,  A,XFFst(M')  h  Sr(X^)  <  R. 

(i)  Thus,  by  Transitivity,  A,  X‘^:Fst(M')  h  R'  <  R. 

(j)  Inductively,  by  Corollary  6.3.1,  A  h  p  (R')  <  pX.R. 

2.  Analogous  to  the  proof  of  Part  1,  replacing  occurrences  of  <  with  =. 

3.  (a)  Let  R' =  5R.[Ci/x^](Cj). 

(b)  Since  5si(Cj)  =  p  (R^),  we  need  to  show  that  A  h  p  (R'^)  <  p  (R2). 

(c)  By  assumption,  A  h  Fst(Ri)  <  Fst(R2)  and  A, X'^:Fst(Ri)  I-5r^(X'^)  <  Sr2(X'^). 

(d)  Since  A  h  Ci  =  C2  :  Fst(Ri),  by  Functionality,  A  h  R'^  <  R2. 

(e)  Inductively,  by  Corollary  6.3.1,  A  h  /9(Ri)  <  p(^2)- 


Corollary  6.3.1  (Admissible  Rds  Rules) 

Suppose  A  h  pX.Si  sig  and  A  h  /JX.S2  sig. 

1.  If  A  h  Fst(Si)  =  Fst(S2)  and  A,XFFst(Si)  h  Si  =  S2,  then  A  h  pX.Si  =  pX.Sa. 

2.  If  A  h  Fst(Si)  <  Fst(S2)  and  A,XFFst(Si)  h  Si  <  S2,  then  A  h  pX.Si  <  pX.S2. 

Proof:  Follows  directly  from  Part  3  of  Proposition  4.1.9.  ■ 

Figure  6.13  presents  the  phase-splitting  rules  for  the  new  signature  constructs.  The  rule  for 
maybe(S)  makes  clear  that  the  maybe  only  applies  to  the  dynamic  part  of  S.  The  rule  for  pX.S  is 
the  same  as  the  one  given  in  Section  5.2.2;  thanks  to  the  dynamic-on-static  restriction,  all  recursive 
references  to  X  in  S  appear  in  the  dynamic  part  of  S,  so  the  phase-splitting  rule  can  replace  them 
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Modules  M,  N,  F  ::=  •••  |  rec(X:§.  M)  |  fetch(M)  |  roll(M)  |  unroll(M) 

Projectible  Modules  M,N,F  ::=  •••  |  rec(X:S.M)  |  fetch(M)  |  roll(M)  |  unroll(M) 

Fst(rec(X;S.M))  =  Can(Fst(S)) 

Fst(fetch(M))  Fst(M) 

Fst(roll(M))  =  Fst(M) 

Fst(unroll(M))  =  Fst(M) 

Figure  6.14:  Extensions  to  Module  Syntax 


with  direct  references  to  the  variable  a.  I  give  here  the  proof  of  the  one  new  and  interesting  case 
in  the  soundness  theorem. 

Proposition  4.1.10  (Soundness  and  Other  Properties  of  Signature  Phase-Splitting) 

5.  If  A  h  Si  <  S2  and  Si  =1  |q;:Ki.Ci]  and  S2  =1  |a:K2.C2|, 
then  A  h  Ki  <  K2  and  A,  a:Ki  h  Ci  =  C2  :  T. 

Proof: 

5.  New  case:  Si  =  pX.R*  and  Sj  =1  |a:Kj.Ci[a/X'^]],  where  R*  =1  |a:Kj.Cj]. 

(a)  By  assumption,  A  h  Fst(Ri)  <  Fst(R2)  and  A, X‘^:Fst(Ri)  FSrj(X‘^)  <  Sr2(X‘^)- 

(b)  By  Part  2  of  this  proposition,  Kj  =  Fst(Rj),  so  A  F  Ki  <  K2. 

(c)  By  induction,  SRi(X^)  ^  |Q;:Lj.Dj, 

(d)  where  A,  X‘^:Ki  h  Li  <  L2  and  A,  X'^:Ki,  q;:Li  h  Di  =  D2  :  T. 

(e)  By  Proposition  4.1.9,  A,X‘^:Ki  FSr.(X'^)  <  Rj. 

(f)  By  induction,  A,X'^:Ki  F  Lj  <  Kj  and  A,  X'^:Ki,  a:Lj  F  Dj  =  C*  :  T. 

(g)  By  Transitivity,  A, X'^:Ki, a:Li  F  Ci  =  C2  :  T. 

(h)  By  Substitution,  A,a:Ki  F  Ci[a/X'^]  =  C2[q;/X‘^]  :  T. 


6.4  Module-Language  Extensions 

Figure  6.14  shows  the  extensions  to  the  syntax  of  modules.  The  recursive  module  construct 
rec(X :  S.  M)  requires  the  declared  signature  to  be  transparent.  As  explained  in  Chapter  5,  this  is 
the  only  simple,  type-theoretic  approach  I  know  of  for  addressing  the  double  vision  problem.  Since 
rec(X :  S.  M)  is  transparent,  it  is  considered  projectible  as  well.  The  static  part  of  rec(X :  §.  M)  is 
defined  as  the  canonical  implementation  of  Fst(S),  although  any  implementation  of  Fst(S)  will  do. 

The  module  fetch  (M)  evaluates  M  to  a  memory  location  and  then  dereferences  the  memory 
location.  If  the  contents  of  the  location  are  undefined,  then  a  run-time  error  is  raised.  As  discussed 
in  Section  6.3,  Fst(maybe(S))  =  Fst(S).  Correspondingly,  fetch (M)  is  projectible  so  long  as  M  is, 
and  Fst(fetch(M))  =  Fst(M). 
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Well-formed  modules:  F  h  M  S 


r,X:maybe(S)  h  M  :p  S  F  h  M  maybe(S) 

F  h  rec(X ;  S.  M)  :p  S  ^  ^  F  h  fetch(M)  S  ^  ^ 


F  h  M  S 


Fhroll(M)  :,p(S) 


(124) 


F  h 


•p 


pX.S 


F  h  unroll(M)  :p  S[M/X] 


(125) 


Figure  6.15;  New  Inference  Rules  for  Modules 


The  modules  roll(M)  and  unroll(M)  are  the  introduction  and  elimination  forms  for  rds’s,  re¬ 
spectively.  They  are  merely  signature  coercions  and  have  no  run-time  effect.  Thus,  as  the  phase- 
splitting  rules  for  modules  will  evidence,  roll(M)  and  unroll(M)  have  exactly  the  same  core-language 
interpretation  as  M  does,  and  Fst(roll(M))  =  Fst(unroll(M))  =  Fst(M). 

Figure  6.15  gives  the  typing  rules  for  these  new  module  constructs.  Rule  122  for  rec(X:S.  M) 
requires  that  M  have  signature  §,  assuming  X  is  a  location  that  will  eventually  store  the  result  of 
evaluating  M.  Rule  123  says  that  fetch(M)  is  pure  if  M  is.  Rule  124  for  roll(M)  coerces  M  into 
an  rds  by  wrapping  the  signature  of  M  in  a  degenerate  rds.  Rule  125  restricts  the  argument  of 
unroll(M)  to  be  projectible,  so  that  Fst(M)  may  be  substituted  for  X*^  in  the  body  of  the  rds  pX.S 
classifying  M. 

It  is  easy  to  show  that  the  declarative  properties  of  modules  given  in  Section  4.2.4  are  preserved 
by  the  present  extensions.  One  point  of  note:  the  rule  for  rds  introduction  given  here  as  Rule  124 
is  simpler  than  the  rule  suggested  initially  in  Section  5.2.2.  That  earlier  rule,  which  was  essentially 
the  inversion  of  the  unroll  rule,  is  admissible  in  the  present  system: 

Proposition  6.4.1  (Admissible  Roll  Rule) 

If  F  h  pX.S  sig  and  F  h  M  :p  S[M/X],  then  F  h  roll(M)  :p  pX.S. 

Proof: 

1.  Let  R  =  Ss[Fst(M)/x4(Fst(M)). 

2.  Since  F  h  M  :p  S[M/X],  by  Rule  102,  F  h  M  :p  M. 

3.  Thus,  by  Rule  124,  F  h  roll(M)  :p  p(M).  We  need  to  show  that  F  h  p(M)  <  pX.S. 

4.  First,  since  F  h  pX.S  sig,  we  have  F  h  Fst(S)  kind. 

5.  Thus,  X"  0FV(Fst(S)),  and  Fst(S[M/X])  =  Fst(S)[M/X]  =  Fst(S). 

6.  By  Proposition  4.1.3,  F  h  Fst(M)  =  5F5t(g)(Fst(M)). 

7.  By  Proposition  4.2.3,  F  h  Fst(M)  :  Fst(S). 

8.  Thus,  by  Proposition  3.1.12,  F  h  Fst(M)  :  Fst(M)  and  F  h  Fst(M)  <  Fst(S). 

9.  By  Proposition  3.1.14,  F,X'^:Fst(M)  h  Fst(M)  =  X'^  ;  Fst(M). 

10.  Since  F,XFFst(M)  h  5s(X^)  <  S,  by  Functionality,  F,XFFst(M)  h  M  <  S. 

11.  Thus,  by  Corollary  6.3.1,  F  h  p(M)  <  pX.S. 
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Signature  synthesis:  F  h  M  S 

r  h  S  sig  r,  X;maybe(S)  h  M  <J=p  S  F  h  M  =>k  maybe(S) 
F  h  rec(X :  §.  M)  S  F  h  fetch (M)  S 

FhM^^S  FhM^P/jX.S 

F  h  roll(M)  p{S)  F  h  unroll(M)  ^p  S[M/X] 

Figure  6.16:  Extensions  to  Signature  Synthesis 


Figure  6.16  shows  how  to  extend  the  signature  synthesis  algorithm  to  handle  the  new  module 
constructs.  All  the  new  synthesis  rules  are  straightforward.  Here  are  the  new  cases  in  the  proof 
that  the  signature  checking  algorithm  is  complete: 

Theorem  4.2.6  (Completeness  of  Signature  Checking) 

If  F  h  M  S,  then  F  h  M  S. 

Proof: 

•  Case:  Rules  122  and  123.  Trivial. 

•  Case:  Rule  124. 

1.  By  induction,  F  h  M  R;  where  F  h  R  <  S  and  n'  C  n. 

2.  Thus,  F  h  roll(M)  /o(R))  and  by  Corollary  6.3.1,  F  h  /o(R)  <  p(S). 

•  Case:  Rule  125. 

1.  By  induction,  F  h  M  =^p  pXM  and  F  h  pXM  <  pX.S. 

2.  Thus,  F  h  unroll(M)  ^p  R[M/X]. 

3.  By  Soundness  and  Proposition  4.1.3,  F  h  Fst(M)  :  Fst(M). 

4.  By  inversion  on  subtyping,  F  h  Fst(M)  <  Fst(S)  and  F,X'^:Fst(R)  h  Sr(X‘^)  <  Ss(X'^). 

5.  By  Proposition  4.1.9,  F,XFFst(R)  h  R  =  5r(X")  and  F,XFFst(R)  h  Ss(X")  <  S. 

6.  By  Transitivity,  F,X‘^:Fst(R)  h  R  <  S. 

7.  By  Substitution,  F  h  R[M/X]  <  S[M/X]. 


Finally,  Figure  6.17  gives  the  phase-splitting  rules  for  the  new  module  constructs.  The  rules 
for  roll(M)  and  unroll(M)  show  that  these  are  merely  retyping  operations,  which  have  no  effect  on 
either  the  static  or  dynamic  part  of  M.  The  rules  for  fetch  (M)  show  that  the  only  part  of  M  that 
actually  needs  to  be  fetched  from  memory  is  its  dynamic  part.  The  rule  for  recursive  modules 
illustrates  that  the  recursion  only  applies  to  the  dynamic  part  of  the  recursive  module  body,  since 
the  static  part  is  fully  specihed  by  the  transparent  declared  signature.  It  is  easy  to  check  that  these 
new  cases  preserve  the  soundness  of  phase-splitting  (Proposition  4.2.7). 
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Pure  module  phase-splitting:  F  h  M  =^p  S  [C,e] 

r  h  §  |XFIC.C|  r,X:maybe(§)  h  M  [D,e]  T,  X;maybe(§)  h  R  <  § 

r  h  rec(X :  S.  M)  ^p  S  [Can(]K),  let  X^  =  Can(IK)  in  rec(X'' :  C.  e)] 

r  h  M  =^p  maybe(S)  [C,  e] 
r  h  fetch (M)  ^p  S  ^  [C,  fetch  (e)] 

rhM^P  [C,e]  rhM^P/)X.S=^  [C,e] 

r  h  roll(M)  p{S)  ^  [C,e]  T  h  unroll(M)  ^p  S[M/X]  ^  [C,e] 

Impure  module  packaging:  ThM^i  S^e 

r  h  M  =^i  maybe(S)  e 

r  h  fetch(M)  S  ^  let  [a,  x]  =  unpack  e  in  pack  [a,  fetch(x)]  as  {|S^ 

r  h  M  S  ^  e 
r  h  roll(M)  =^i  p  (S)  ^  e 


Figure  6.17:  New  Module  Phase-Splitting  Rules 


Chapter  7 

Safe  Recursion 


I  argued  in  Section  5.2.1  that  the  backpatching  semantics  for  recursive  modules  is  superior  to  a 
fixed-point  semantics,  because  it  ensures  that  any  computational  effects  in  the  recursive  module 
body  will  only  happen  once  and  not  be  repeated  at  each  use  of  the  recursive  module  variable. 
However,  in  the  recursive  module  proposal  that  I  sketched  in  Section  5.4  (and  that  I  will  formalize 
in  Part  III),  the  typechecker  makes  no  attempt  to  detect  statically  whether  or  not  recursion  is 
safe}  That  is,  given  a  recursive  module  rec(X:S.M),  the  typechecker  cannot  guarantee  that  the 
evaluation  of  M  will  not  prompt  the  dereferencing  of  X  before  it  has  been  backpatched.  As  a  result, 
whenever  X  is  dereferenced  (by  fetch  (X)),  there  is  a  possibility  that  it  has  not  yet  been  backpatched, 
in  which  case  a  run-time  error  must  be  raised. 

While  dynamic  detection  of  unsafe  recursion  has  the  benefit  of  simplicity,  compile-time  detection 
would  be  preferable  if  it  could  be  done  in  a  manner  that  is  not  overly  conservative.  Furthermore, 
statically  ensuring  safe  recursion  would  allow  recursive  modules  to  be  implemented  more  efficiently. 
In  the  absence  of  static  detection,  there  are  two  well-known  implementation  choices:  1)  the  recursive 
variable  X  can  be  implemented  as  a  pointer  to  a  value  of  option  type  (initially  NONE),  in  which 
case  every  dereference  of  X  must  also  perform  a  tag  check  to  see  if  it  has  been  backpatched  yet,  or 
2)  X  can  be  implemented  as  a  pointer  to  a  thunk  (initially  fn  ()  =>  raise  Error),  in  which  case 
dereferencing  X  does  not  require  a  tag  check  but  instead  incurs  a  function  call.  Either  way,  mutually 
recursive  functions  defined  across  module  boundaries  may  be  noticeably  slower  than  ordinary  ML 
functions.  If  recursion  is  statically  determined  to  be  safe,  though,  the  value  pointed  to  by  X  will 
be  needed  only  after  X  has  been  backpatched,  so  each  fetch  (X)  will  require  only  a  single  pointer 
dereference. 

In  this  chapter,  I  consider  the  problem  of  statically  detecting  whether  recursion  under  a  back- 
patching  semantics  is  safe.  In  order  to  simplify  matters  and  isolate  orthogonal  concerns,  I  will 
ignore  the  issues  involving  type  components  in  recursive  modules  and  focus  attention  on  their  dy¬ 
namic  components.  In  particular,  I  will  consider  the  semantics  of  a  safe  recursive  term  construct 
saferec(x  :  C.  e)  in  the  context  of  the  simply-typed  A-calculus.  Even  in  the  limited  setting  of  the 
simply- typed  A-calculus,  the  safe  recursion  problem  is  quite  interesting  and  difficult,  and  there  has 
been  little  previous  work  on  it. 

The  chapter  is  structured  as  follows;  In  Section  7.1,  I  introduce  the  property  of  evaluability, 
which  guarantees  that  a  term  is  safe  to  evaluate  even  if  it  has  free  references  to  undefined  recur¬ 
sive  variables.  I  consider  a  simple  straw-man  approach  to  tracking  evaluability,  and  illustrate  by 

^In  Dreyer  [10],  I  used  the  term  well-founded  recursion  instead  of  safe  recursion.  Both  terms  appear  in  the 
literature,  but  the  former  gives  the  impression  of  similarity  to  well-founded  induction  when  there  is  none.  I  have 
therefore  opted  to  use  the  latter  term  in  this  chapter. 
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examples  why  a  more  sophisticated  approach  is  required. 

In  Section  7.2,  I  propose  a  type-theoretic  approach  to  resolving  these  problems.  The  basic  idea 
is  to  model  recursive  variables  statically  as  names,  and  to  use  names  to  track  the  set  of  recursive 
variables  that  a  piece  of  code  may  attempt  to  dereference  when  evaluated.^  Names  are  useful  for 
two  purposes:  (1)  tracking  uses  of  multiple  recursive  variables  in  the  presence  of  nested  recursion, 
and  (2)  supporting  separate  compilation  of  safe  recursive  terms/modules.  An  equally  important 
feature  of  my  approach  is  that  recursive  terms/modules  may  invoke  “legacy”  functions  defined 
in  existing  ML  code  without  requiring  them  to  be  changed  or  recompiled  to  account  for  name 
reasoning.  Nevertheless,  as  I  discuss  in  Section  7.2.3,  there  are  useful  recursive  module  idioms  for 
which  instrumentation  of  existing  ML  code  appears  to  be  unavoidable  if  one  wants  to  statically 
ensure  that  the  recursion  is  safe. 

Interestingly,  while  computational  effects  are  what  necessitate  the  backpatching  semantics  of 
recursion,  all  of  the  subtleties  involving  names  are  explored  in  Section  7.2  in  the  setting  of  the 
pure  A-calculus.  Section  7.3  introduces  computational  effects  into  the  language  in  the  form  of 
mutable  state  and  continuations,  but  these  extensions  turn  out  to  be  rather  simple,  orthogonal, 
and  oblivious  to  the  presence  of  names. 

In  Section  7.4,  I  show  how  the  unrestricted  recursive  term  construct  rec(x  :  C.  e)  (whose  seman¬ 
tics  was  formalized  in  Section  6.2  of  the  previous  chapter)  may  be  encoded  in  terms  of  the  safe 
recursive  construct  saferec(x  :  C.  e)  by  extending  the  language  with  memoized  computations.  While 
the  unrestricted  construct  does  not  statically  ensure  safe  recursion,  it  is  useful  to  have  as  a  fallback 
in  circumstances  where  the  type  system  is  too  weak  to  observe  that  a  safe  recursive  term  is  in  fact 
safe. 

In  Section  7.5,  I  compare  my  approach  with  related  work  on  safe  recursion  and  backpatching 
semantics.  Finally,  in  Section  7.6,  I  discuss  the  key  issues  and  difficulties  I  foresee  in  scaling  my 
approach  to  the  level  of  a  realistic  ML  extension. 


7.1  Evaluability 

Recall  the  recursive  construct  rec(a: :  C.  e)  introduced  in  Section  6.2.  The  typing  rule  for  rec(x  :  C.  e) 
checks  that  e  has  type  C  in  a  context  where  x  has  type  maybe(C).  To  dereference  x,  we  write 
fetch  (x). 

Now  consider  a  “safe”  recursive  construct  of  the  form  saferec(x :  C.  e).  What  must  we  require 
of  e  to  ensure  that  saferec(x :  C.  e)  is  in  fact  safe?  Crary  et  al.  [6]  require  that  e  be  valuable  (that 
is,  pure  and  terminating)  in  a  context  where  x  is  not.  Let  us  generalize  their  notion  of  valuability 
to  one  permitting  effects,  which  I  will  call  evaluability.  A  term  may  be  judged  “evaluable”  if  its 
evaluation  does  not  dereference  any  undehned  {i.e.,  unbackpatched)  recursive  variable.  Thus,  to 
ensure  saferec(x  :  C.  e)  is  safe,  the  expression  e  must  be  evaluable  in  a  context  where  dereferences  of 
the  variable  x  are  considered  non-evaluable.  A  term  can  be  non-evaluable  and  still  be  well-formed, 
but  only  evaluable  expressions  are  safe  to  evaluate  in  the  presence  of  undefined  recursive  variables. 

Formally,  we  might  incorporate  evaluability  into  the  type  system  by  dividing  the  typing  judg¬ 
ment  into  one  classifying  evaluable  terms  (F  h  e  J,  C)  and  one  classifying  non-evaluable  terms 
(F  h  e  I  C).  (There  is  an  implicit  inclusion  of  the  former  in  the  latter.)  The  typing  rule  for 

^My  use  of  names  is  inspired  by  the  work  of  Nanevski  on  a  core  langnage  for  metaprogramming  and  symbolic 
computation  [57] ,  although  it  is  closer  in  detail  to  his  work  (concnrrent  with  mine)  on  nsing  names  to  model  control 
effects  [58]. 
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saferec(x  :  C.  e)  might  then  be  as  follows: 

r,  x:box(C)  \-  e  I  C 
r  h  saferec(x  :  C.  e)  J,  C 

To  stress  the  distinction  between  safe  and  unsafe  recursion,  I  have  chosen  here  to  bind  x  with  a 
new  type,  box(C),  instead  of  maybe(C).  To  dereference  a  location  v  of  type  box(C),  we  will  write 
unbox(u). 

It  is  important  to  understand  that  the  distinction  between  box(C)  and  maybe(C),  and  between 
unbox’ing  and  fetch ’ing,  is  not  merely  pedantic.  The  implementation  of  fetch  (u)  must  check  to 
make  sure  that  v  has  been  backpatched,  whereas  the  implementation  of  unbox(t>)  need  not  perform 
any  such  check — the  static  semantics  will  guarantee  that  v  will  not  be  unbox’ed  until  it  has  been 
backpatched.  To  validate  this  guarantee,  the  typing  rule  for  unbox(u)  must  be  conservative  and 
treat  all  unboxing  operations  as  potentially  non-evaluable; 

r  h  u  I  box(C) 
r  h  unbox(u)  I  C 

7.1.1  The  Evaluability  Judgment 

While  true  evaluability  is  clearly  an  undecidable  property,  there  are  certain  kinds  of  expressions  that 
we  can  expect  the  type  system  to  recognize  as  evaluable.  Certainly  all  values  and  projections  from 
values  should  be  considered  evaluable,  as  should  all  let-expressions  whose  constituent  expressions  are 
evaluable.  There  is  no  reason  to  limit  evaluability  to  pure  expressions  either.  For  instance,  the  ML 
expressions  ref  (e) ,  !  e,  and  ei :  =  62  should  all  be  evaluable  as  long  as  their  constituent  expressions 
are.  Given  this  characterization,  we  can  already  observe  that  the  effectful  recursive  module  example 
in  Figure  5.6  from  Chapter  5  is  safe.  Evaluability  is  thus  independent  of  computational  purity  in 
the  traditional  sense. 

There  is,  however,  a  correspondence  between  non-evaluability  and  computational  fm-purity  in 
the  sense  that  both  are  hidden  by  A-abstractions  and  unleashed  by  function  applications.  In  ML  we 
assume  (for  the  purpose  of  the  value  restriction  on  let-polymorphism)  that  all  function  applications 
are  potentially  impure.  In  the  current  setting  we  might  similarly  assume  for  simplicity  that  all 
function  applications  are  potentially  non-evaluable. 

Unfortunately,  this  assumption  has  one  major  drawback:  it  implies  that  we  can  never  evaluate 
a  function  application  inside  the  body  of  a  recursive  term!  Furthermore,  it  is  usually  unnecessary: 
while  functions  dehned  inside  a  recursive  term  may  very  well  be  concealing  references  to  an  unde- 
hned  recursive  variable,  functions  dehned  in  existing  ML  code  will  not.  For  example,  suppose  we 
were  to  modify  the  example  of  Figure  5.6  in  the  manner  shown  in  Figure  7.1.  Instead  of  dehning 
A. debug  as  a  boolean  hag  (ref  false),  the  new  version  dehnes  it  as  a  mutable  array,  by  a  call 
to  the  array  creation  function  Array. array.  The  call  to  Array. array  is  perfectly  evaluable.  In 
contrast,  a  call  to  the  function  A.f  from  within  the  recursive  module  would  not  be,  since  the  body 
of  A.f  makes  a  recursive  call  to  unbox (X)  .B.g.  Lumping  them  together  and  assuming  the  worst 
makes  the  evaluability  judgment  overly  conservative. 

7.1.2  A  Total/Partial  Distinction 

At  the  very  least,  then,  we  should  make  a  type  distinction  between  functions  whose  bodies  are 
evaluable  and  those  whose  bodies  are  not.  Thinking  of  non-evaluability  as  a  sort  of  computational 
effect,  let  us  refer  to  the  hrst  type  of  function  as  “total”  (written  Ci  C2)  and  to  the  latter  type 
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saferec  (X  :  SIG. 
struct 

structure  A  =  struct 

val  debug  =  Array . array (ii,0) 
fun  f (x)  =  . . .unbox(X) .B.g(x+1) . . . 

end 

structure  B  =  struct  . . .  end 
end) 

Figure  7.1:  Modified  Example  of  Recursive  Module  With  Effects 


as  “partial”  (written  Ci  C2).^  The  typing  rules  for  total  and  partial  A- abstractions  would  then 
be  as  follows; 

r,x:DI-e|C  r,x:DI-etC 

FhAxiD.eiD^C  FhAxiD.eiD^C 

Correspondingly,  applications  of  total  functions  will  be  deemed  evaluable,  whereas  applications  of 
partial  functions  will  be  assumed  non-evaluable; 

FhxiiD^C  FhuaiD  FbuiiD^C  FhxsiD 

rhui(x2)ic  rhxi(x2)TC 

The  total/partial  distinction  addresses  the  concerns  discussed  in  the  previous  section,  to  an  extent. 
Existing  ML  functions  can  now  be  classified  as  total,  and  the  arrow  type  Ci  ->C2  in  ML  proper 
is  synonymous  with  a  total  arrow.  Thus,  we  may  now  evaluate  calls  to  existing  ML  functions  in 
the  presence  of  undefined  recursive  variables,  as  those  function  applications  will  be  known  to  be 
evaluable.  Nonetheless,  some  serious  problems  remain. 

7.1.3  Limitations  of  the  Total/Partial  Distinction 

First,  consider  what  happens  if  we  use  the  safe  recursive  construct  to  define  a  single  recursive 
function,  such  as  factorial: 

saferecff  :  int  int .  fn  x  =>  ...  x  *  unbox (f ) (x-1)  ...) 

Note  that  we  are  forced  to  give  the  recursive  expression  a  partial  arrow  type  because  the  body 
of  the  factorial  function  unboxes  the  recursive  variable  f.  Nonetheless,  exporting  factorial  as  a 
partial  function  is  bad  because  it  means  that  no  application  of  factorial  can  ever  be  evaluated 
inside  another  recursive  expression! 

To  mend  this  problem,  we  observe  that  while  the  factorial  function  is  indeed  partial  during  the 
evaluation  of  the  general  recursive  expression  defining  it,  it  becomes  total  as  soon  as  f  is  backpatched 
with  a  definition.  One  way  to  incorporate  this  observation  into  the  type  system  is  to  revise  the 
typing  rule  for  recursive  terms  saferec(x :  C.  e)  so  that  we  ignore  partial/total  discrepancies  when 
matching  the  declared  type  C  with  the  actual  type  of  e.  For  example,  in  the  factorial  definition 

®Note:  This  total/partial  distinction  is  completely  unrelated  to  the  total/partial  distinction  on  functors  from 
Chapter  4,  which  corresponds  to  applicative  vs.  generative  behavior. 
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above,  we  would  allow  f  to  be  declared  with  a  total  arrow  int  — >  int,  since  the  body  of  the 
definition  has  an  equivalent  type  modulo  a  partial/total  mismatch. 

Unfortunately,  such  a  revised  typing  rule  is  only  sound  if  we  prohibit  nesting  of  recursive  terms. 
Otherwise,  the  rule  may  allow  a  truly  partial  function  to  be  erroneously  assigned  a  total  type,  as 
the  following  code  illustrates: 

saferec  (x 
let 

val  f 
in 

fO 

end 

) 

The  trouble  here  is  that  the  evaluation  of  the  recursive  term  defining  f  results  only  in  the  back- 
patching  of  y,  not  X.  It  is  therefore  unsound  for  that  term  to  make  the  type  of  fn  ()  =>  unbox  (x) 
total.  In  short,  the  problem  is  that  the  total/partial  dichotomy  is  too  coarse  because  it  does  not 
distinguish  between  the  dereferencing  of  different  recursive  variables.  In  the  type  system  of  Sec¬ 
tion  7.2,  we  will  be  able  to  give  f  a  more  appropriate  type  specifying  that  f  will  dereference  x  when 
applied,  but  not  y. 

Another  problem  with  the  total/partial  distinction  arises  in  the  use  of  higher-order  functions. 
Suppose  we  wish  to  use  the  Standard  Basis  map  function  for  lists,  which  can  be  given  the  following 
type  (for  any  D  and  C): 

val  map  :  (D  C)  (D  list  C  list) 

Since  the  type  of  map  is  a  pure  ML  type,  all  the  arrows  are  total,  which  means  that  we  cannot 
apply  map  to  a  partial  function,  as  in  the  following; 

saferec  (X  :  SIG. 
let 

val  f  :  D  ^  C  =  . .  . 

val  g  :  D  list  C  list  =  map  f 


:  C. 

=  saferec (y  :  unit  C.  fn  ()  =>  unbox (x)) 


) 

Given  the  type  of  map,  this  is  reasonable:  unless  we  know  how  map  is  implemented,  we  have  no  way 
of  knowing  that  evaluating  map  f  will  not  try  to  apply  f ,  resulting  in  a  potential  dereference  of  X. 

Nevertheless,  we  should  at  least  be  able  to  replace  map  f  with  fn  xs  =>  map  f  xs,  its  eta- 
expansion,  which  is  clearly  evaluable  since  it  is  a  value.  Even  its  eta-expansion  is  ill-typed,  however, 
because  the  type  of  f  still  does  not  match  the  argument  type  of  map.  The  way  I  propose  to 
resolve  this  problem  is  to  view  a  partial/total  type  mismatch  not  as  a  sign  that  the  offending 
expression  (in  this  case,  map  f)  is  ill-typed,  but  merely  that  it  is  potentially  non-evaluable.  The 
type  system  of  Section  7.2  will  reflect  this  intuition,  and  will  correspondingly  consider  the  function 
fn  xs  =>  map  f  xs  to  be  well-typed  with  a  partial  arrow,  but  not  a  total  one. 

7.2  A  Type  System  for  Safe  Recursion 

In  this  section  I  present  a  type  system  for  safe  recursion  that  addresses  both  of  the  problems 
enumerated  in  the  previous  section.  To  address  the  nested  recursion  problem,  I  generalize  the 
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Variables 

x,y,z 

G 

Variables 

Names 

x,y,z 

G 

Names 

Supports 

S,T 

G 

Vfin(Names) 

Types 

C,D 

:= 

unit  1  Cl  X  C2  1  Cl  ^  C2  1  yX.C  1  box5(C) 

Values 

V 

;  = 

X  ()  (vi,V2)  X^x'.C.e  XX.e 

Terms 

e,/ 

:= 

V  TTi(v)  1  vi(v2)  v(S)  box5(i;)  unbox(i;) 
let  X  =  Cl  in  62  saferec(A’  >  x  :  C.  e) 

Typing  Contexts 

F 

::= 

0  1  F,x  :  C  1  F,V 

Figure  7.2:  Syntax  of  Safe  Recursion  Language 


judgment  of  evaluability  to  one  that  tracks  uses  of  individual  recursive  variables.  I  achieve  this  by 
introducing  along  with  each  recursive  variable  x  a  name  X  that  is  used  as  a  static  representative 
of  the  variable.  The  new  evaluability  judgment  has  the  form  F  h  e  :  C  [5],  with  the  interpretation 
“under  context  F,  term  e  has  type  C  and  is  evaluable  modulo  the  names  in  set  5”.  In  other 
words,  e  will  evaluate  without  dereferencing  any  recursive  variables  except  possibly  those  whose 
associated  names  appear  in  <5.  Following  Nanevski  [57],  I  call  a  finite  set  of  names  a  support.  Our 
previous  judgment  of  evaluability  (F  h  e  J,  C)  can  be  understood  as  evaluability  modulo  the  empty 
support  (F  h  e  :  C  [0]),  while  non-evaluability  (F  h  e  |  C)  corresponds  to  evaluability  modulo  some 
non-empty  support. 

Similarly,  I  will  generalize  the  types  of  functions  to  bear  a  support  indicating  which  particular 
recursive  variables  may  be  dereferenced  in  their  bodies.  Thus,  the  total  arrow  type  of  the  previous 
section  becomes  an  arrow  type  bearing  empty  support,  while  the  partial  arrow  type  corresponds  to 
an  arrow  type  bearing  some  non-empty  support. 

To  address  the  higher-order  function  problem,  I  employ  a  novel  judgment  of  type  equivalence 
modulo  a  support,  which  allows  type  mismatches  in  an  expression  to  be  ignored  so  long  as  they 
only  involve  names  that  are  in  the  support  of  the  expression.  The  intuition  behind  this  judgment 
is  as  follows.  If  a  name  X  is  in  the  support  of  an  expression  e,  then  the  evaluation  of  e  may 
dereference  the  recursive  variable  x  to  which  X  corresponds.  The  type  system  must  therefore 
ensure  that  x  is  backpatched  before  e  is  ever  evaluated.  Once  x  is  backpatched,  however,  the  effect 
of  dereferencing  it  becomes  benign,  and  the  name  X  can  subsequently  be  ignored.  Thus,  since  e 
will  only  be  evaluated  after  x  has  been  backpatched,  type  mismatches  regarding  X  are  irrelevant 
as  far  as  the  typechecking  of  e  is  concerned. 

7.2.1  Syntax 

The  syntax  of  the  language  is  given  in  Figure  7.2.  I  assume  the  existence  of  countably  infinite 
sets  of  names  (Names)  and  variables  (Variables),  and  use  S  and  T  to  range  over  supports.  I  will 
sometimes  write  the  name  X  as  shorthand  for  the  singleton  support  {X}. 

The  type  structure  of  the  language  is  as  follows.  Unit  (unit)  and  pair  types  (Ci  x  C2)  require 

no  explanation.  An  arrow  type  (Ci  — >  C2)  bears  a  support  S  on  the  arrow,  which  indicates  the 
names  whose  associated  recursive  variables  must  be  backpatched  before  a  function  of  this  type  may 
be  applied.  Similarly,  A-abstractions  A^x:D.e  explicitly  specify  the  support  T  required  for  them 
to  be  applied.  I  will  write  Ci  — >  C2  (resp.  Ax  ;  D.  e)  as  shorthand  for  Ci  — >  C2  (resp.  A®x  :  D.  e). 
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The  language  also  provides  the  ability  to  abstract  a  term  over  a  name.  The  type  VT’.C  classifies 
name  abstraction  values  XA.e.  Application  of  a  name  abstraction,  v{S),  allows  the  name  parameter 
of  V  to  be  instantiated  with  a  support  S,  not  just  a  single  name.  The  reasons  for  allowing  names 
to  be  instantiated  with  supports  are  discussed  in  Section  7.2.3. 

Lastly,  the  location  type  box5(C)  classifies  a  memory  location  that  will  contain  a  value  of  type  C 
once  the  recursive  variables  associated  with  the  names  in  S  have  been  backpatched.  Locations  are 
most  commonly  introduced  by  recursive  terms.  The  recursive  term  construct  saferec(A’  >  x  :  C.  e) 
binds  both  the  name  A  and  the  variable  x  in  e.  The  type  of  x  will  be  box;i'(C),  indicating  that 
X  may  only  be  unboxed  by  an  expression  with  support  containing  X.  The  box5(C)  type  may 
also  be  introduced  by  box5(u),  which  creates  a  new  memory  location  and  stores  v  at  it.  As  this 
is  an  effectful  operation,  box5(u)  is  not  a  value — the  only  values  of  box  type  are  variables.  The 
elimination  form  for  box  types  is  unbox(u),  which  dereferences  the  location  v.  I  will  sometimes 
write  box(C)  (resp.  box(u))  as  shorthand  for  box0(C)  (resp.  box0(u)). 

For  notational  convenience,  I  will  enforce  several  implicit  requirements  on  the  syntactic  well- 
formedness  of  contexts  and  judgments.  A  context  T  is  well-formed  if  (1)  it  does  not  bind  the  same 
variable/name  twice,  and  (2)  for  any  prefix  of  T  of  the  form  T' ,x  :  C,  the  free  names  of  C  are  bound 
in  r'.  A  judgment  of  the  form  T  h  77  is  well-formed  if  (1)  T  is  well-formed,  and  (2)  any  free  names 
appearing  in  J  are  bound  in  T.  I  assume  and  maintain  the  implicit  invariant  that  all  contexts  and 
judgments  are  well-formed. 

7.2.2  Static  Semantics 

The  main  typing  judgment  has  the  form  T  h  e  :  C  [5].  The  support  S  represents  the  set  of 
names  whose  associated  recursive  variables  we  may  assume  have  been  backpatched  by  the  time  e  is 
evaluated.  Put  another  way,  the  only  recursive  variables  that  e  may  dereference  are  those  associated 
with  the  names  in  S.  The  static  semantics  is  carefully  designed  to  validate  this  assumption. 

The  rules  of  the  type  system,  shown  in  Figure  7.3,  are  designed  to  make  admissible  the  principle 
of  support  weakening,  which  says  that  if  F  h  e  :  C  [5]  then  F  h  e  :  C  [T]  for  any  T  D  S.  Thus, 
for  instance,  since  a  variable  x  does  not  require  any  support.  Rule  1  allows  x  to  be  assigned  any 
support  S  C  dom(r),  not  just  the  empty  support. 

The  remainder  of  the  rules  may  be  summarized  as  follows.  Unit,  pairs  and  projections  need  no 
support  (Rules  2,  3  and  4).  A  function  x  :  D.  e  has  type  D  C  in  any  support  S,  so  long  as  the 
body  e  is  well- typed  under  the  addition  of  support  T  (Rule  5).  To  evaluate  a  function  application 
vi{v2),  the  support  S  must  contain  the  support  T  on  ui’s  arrow  type  (Rule  6). 

Although  a  name  abstraction  XX. e  suspends  the  evaluation  of  e,  the  body  is  typechecked  under 
the  same  support  as  the  abstraction  itself  (Rule  7).  In  other  words,  one  can  view  VA.C  as  another 
kind  of  arrow  type  that  always  bears  empty  support  (compare  with  Rule  5  when  T  =  0).  Note  also 
that  the  assumptions  about  the  well-formedness  of  judgments  ensure  that  the  support  S  cannot 
contain  X,  since  S  C  dom(F)  and  X  ^  dom(F).  Restricting  name  abstractions  in  this  way  is 
motivated  by  the  fact  that,  in  all  my  intended  uses  of  name  abstractions  (see  Section  7.2.3  below), 
the  body  of  the  abstraction  is  a  value  (with  empty  support). 

Instantiating  a  name  abstraction  v  of  type  VA.C  with  a  support  T  has  the  type  resulting  from 
substituting  T  for  A  in  C  (Rule  8).  The  substitution  C[T / X\  is  defined  by  replacing  every  support 
S  appearing  in  C  with  S\T j X\,  which  is  in  turn  defined  as  follows: 


drf  {  SOT- {X}  EXgS 
~  \  S  if  A  0  5 
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Well-formed  terms:  F  h  e  :  C  [5] 


X  :  C  £  r 
r  h  X  :  C  [5] 


(1) 


r  h  ()  :  unit  [5] 


(2) 


r  h  XI  ;  Cl  [5]  r  h  X2  :  C2  [5] 
rh(xi,X2):CixC2  [5] 


(3) 


r  h  X  :  Cl  X  C2  [5] 
r  h  7r,(x)  :  Ci  [5] 


(4) 


r,  X  :  D  h  e  :  C  [5  U  r] 
r  h  A^x  :  D.  e  :  D  ^  C  [5] 

T,Xhe:C[S] 


T 


(5)  r  h  xi  :  D  ^  C  [5]  r  h  X2  ;  D  [5]  T  C  5 


r  h  A^F-e  ;  Vd^.C  [5] 
r  h  X  :  C  [5  U  T] 


(7) 

(9) 


rhxi(x2)  :C  [5] 
r  h  X  :  yx.c  [5] 
r  h  x(T)  :  C[r/d:’]  [5] 

r  h  X  :  boxr(C)  [5]  T  C  5 


r  h  boxr(x)  :  boxr(C)  [5]  F  h  unbox(x)  :  C  [5] 

F  h  ei  :  D  [5]  F,  x  :  D  h  62  :  C  [5] 


(10) 


F  h  let  X  =  ei  in  62  ;  C  [5] 

F,F',x  :  box;r(C)  h  6  :  D  [5]  F,<FhD  =  C[d^] 


F  h  saferec(d:f  i>  x  :  C.  e)  :  C  [5] 
F  h  6  :  D  [5]  F  h  D  =  C  [5] 
F  h  6  :  C  [5] 


(12) 


(13) 


Type  equivalence:  F  h  Ci  =  C2  [<S] 


(14) 


F  h  Di  =  D2  [5]  F  h  Cl  =  C2  [5] 


F  h  unit  =  unit  [5]  ^  ^  F  h  Di  x  Ci  =  D2  x  C2  [5] 

5  U  5i  =  r  =  5  U  52  F  h  Di  =  D2  [T]  F  h  Ci  =  C2  [T] 


(15) 


F  h  Di  ^  Cl  =  D2  ^  C2  [5] 


(16) 


F,ThCi  =  C2  [5] 

F  h  VT.Ci  =  VT.C2  [5] 


(17) 


5  u  5i  =  T  =  5  U  52  F  h  Cl  =  C2  [T] 
F  h  box5i(Ci)  =  box52(C2)  [5] 


(6) 


(18) 


Figure  7.3:  Static  Semantics  for  Safe  Recursion  Language 


Boxing  a  value  requires  no  support  (Rule  9).  Unboxing  a  value  x  of  type  box7-(C)  is  only 
permitted  if  the  recursive  variables  associated  with  the  names  in  T  have  been  defined,  i.e.,  if  T  is 
contained  in  the  support  5  (Rule  10).  Let-terms  have  the  support  of  their  constituent  expressions. 

Rules  12  and  13  are  the  most  interesting  rules  in  the  type  system  since  they  both  make  use 
of  the  judgment  of  type  equivalence  modulo  a  support,  also  defined  in  Figure  7.3.  The  judgment 
F  h  Cl  =  C2  [5]  means  that  Ci  and  C2  are  equivalent  types  modulo  the  names  in  support  5,  i.e., 

that  Cl  are  C2  are  identical  types  if  we  ignore  all  occurrences  of  the  names  in  5.  For  example, 
0  A’ 

the  types  D  — >  C  and  D  — >  C  are  equivalent  modulo  any  support  containing  X.  In  addition, 
when  checking  equivalence  of  arrow  types  Di  — U  Ci  and  D2  — ^  C2  modulo  5,  we  compare  the 
argument  types  and  result  types  at  the  extended  modulus  5u5i  =  5U52  instead  of  5.  This  makes 
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sense  because  a  function  of  one  of  these  types  may  only  be  applied  with  5u5i  in  the  support.  The 
rule  for  box  can  be  justified  similarly. 

This  notion  of  equivalence  modulo  a  support  is  critical  to  the  typing  of  recursive  terms  (Rule  12). 
Recall  the  factorial  example  from  Section  7.1.2,  adapted  to  the  present  type  system: 

saferec  (T  >  f  :  int  — ^  int. 

fn  X  =>  ...  X  *  unboxCf ) (x-1)  ...) 

iY 

The  issue  here  is  that  the  declared  type  of  f  does  not  match  the  type  of  the  body,  int  — >  int. 
Once  f  is  backpatched,  however,  the  two  types  do  match  modulo  X. 

Correspondingly,  the  typing  rule  for  recursive  terms  saferec(d:’ >x  :  C.  e)  works  as  follows.  First, 
the  context  T  is  extended  with  the  name  X,  as  well  as  the  recursive  variable  x  of  type  box;r(C). 
This  location  type  binds  the  name  and  the  variable  together  because  it  says  that  X  must  be  in 
the  support  of  any  expression  that  attempts  to  dereference  (unbox)  x.  The  rule  then  checks  that 
e  has  some  type  D  in  this  extended  context,  under  a  support  S  that  does  not  include  X  (since  x 
is  undefined  while  evaluating  e).  Finally,  it  checks  that  D  and  C  are  equivalent  modulo  X.  It  is 
easiest  to  understand  this  last  step  as  a  generalization  of  our  earlier  idea  of  ignoring  discrepancies 
between  partial  and  total  arrows  when  comparing  D  and  C.  The  difference  here  is  that  we  ignore 
discrepancies  with  respect  to  a  particular  name  X  instead  of  all  names,  so  that  the  rule  behaves 
properly  in  the  presence  of  multiple  names  (nested  recursion). 

In  contrast.  Rule  13  appears  rather  straightforward,  allowing  a  term  with  type  D  and  support 
S  to  be  assigned  a  type  that  is  equivalent  to  D  modulo  the  names  in  S.  In  fact,  this  rule  solves 
the  higher-order  function  problem  described  in  Section  7.1.2!  Recall  that  we  wanted  to  apply  an 
existing  higher-order  ML  function  like  map  to  a  partial  function,  i.e.,  one  whose  arrow  type  bears 
non-empty  support: 

saferec  (.X  >  x 
let 

val  f  :  D 
val  g  :  D 

) 

The  problem  here  is  that  the  type 
Intuitively,  though,  this  code  ought  to  typecheck:  if  we  are  willing  to  add  X  to  the  support  of  g’s 
arrow  type,  then  x  must  be  backpatched  before  g  is  ever  applied,  so  X  should  be  ignored  when 
typing  the  body  of  g. 

Rule  13  encapsulates  this  reasoning.  Since  g  is  specified  with  type  D  list  — >  C  list,  we 
can  assume  support  X  when  typechecking  its  body  (map  f  xs).  Under  support  X,  Rule  13  allows 

us  to  assign  f  the  type  D  C,  as  it  is  equivalent  to  f’s  type  modulo  X.  Thus,  g’s  body  is 
well-typed  under  support  X. 

7.2.3  Separate  Compilation,  Non-strictness  and  Name  Abstractions 

In  this  section,  I  will  give  some  motivation  for  the  feature  of  name  abstractions,  XX. e.  Recall  that 
the  original  reason  for  making  the  unboxing  (or  fetching)  of  a  recursive  variable  an  explicit  operation 
was  to  support  separate  compilation  of  recursive  modules.  In  the  separate  compilation  scenario 
(Figure  5.11)  described  in  Section  5.2.4,  the  modules  Expr  and  Bind  were  separately  compiled  as 
functors  F_  Expr  and  F_  Bind,  and  linked  together  as  follows: 


:  SIG. 


list  — >  C  list  =  fn  xs  =>  map  f  xs 


of  f  does  not  match  the  argument  type  D  ——>■  C  of  map. 
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F_Expr  =  A;f.  Ax  :  box;t-(EXPR_  BIND) .  ... 

F_Bind  =  AA:”.  Ax  :  box;t-(EXPR_  BIND) .  ... 

saferec  (X  >  X  :  EXPR_BIND. 
struct 

structure  Expr  =  F_  ExprlA:”}  (X) 
structure  Bind  =  F_  BindjA:”}  (X) 
end) 

Figure  7.4:  Revised  Separate  Compilation  Scenario 


saferec  (.X  >  X  :  EXPR_BIND. 
struct 

structure  Expr  =  F_Expr(X) 
structure  Bind  =  F_Bind(X) 
end 

For  the  purposes  of  this  chapter,  since  we  are  ignoring  the  issues  involving  type  components  in 
modules,  let  us  ignore  the  problems  with  using  functors  for  separate  compilation  of  recursive  mod¬ 
ules  (for  instance,  the  double  vision  problem).  Instead,  consider  the  following  question:  how  can 
we  ensure  that  this  recursive  module  linking  Expr  and  Bind  is  safe? 

In  order  for  the  linking  module  to  be  safe,  it  must  be  the  case  that  F_Expr  and  F_Bind,  when 
applied,  do  not  attempt  to  dereference  their  argument.  That  is  to  say,  F_Expr  and  F_Bind  must 
be  non-strict  functors.  What  types  can  we  give  to  F_Expr  and  F_Bind  to  reflect  the  property 
that  they  are  non-strict?  Suppose  that  F_  Expr’s  return  type  is  EXPR.  We  would  like  to  assign  it 

the  type  box;r(EXPR_  BIND)  EXPR,  so  that  (1)  its  argument  type  matches  the  type  of  X,  and 
(2)  the  absence  of  X  on  the  arrow  indicates  that  F_  Expr  can  be  applied  under  empty  support. 
However,  this  type  makes  no  sense  at  the  place  where  F_Expr  is  defined,  because  the  name  X  is 
not  in  scope  outside  of  the  recursive  module. 

This  is  where  name  abstractions  come  in.  To  show  that  F_Expr  is  non-strict,  it  is  irrelevant 
what  particular  support  is  required  to  unbox  its  argument,  so  we  can  use  a  name  abstraction 
to  allow  any  name  or  support  to  be  substituted  for  X.  Figure  7.4  shows  the  resulting  well-typed 
separate  compilation  scenario,  in  which  the  type  of  F_Expr  is  VT.box;f  (EXPR_  BIND)  — ^  EXPR. 

The  recursive  term  construct  is  still  not  quite  as  flexible  for  separate  compilation  purposes  as 
one  might  like.  In  particular,  suppose  that  we  wanted  to  parameterize  F_Expr  over  just  F_Bind 
instead  of  both  F_  Expr  and  F_  Bind.  There  is  no  way  in  our  system  to  extract  a  value  of  type 
box;\f(BIND)  from  X  without  unboxing  it.  It  would  be  easy  to  remedy  this  problem,  however,  by 
generalizing  the  recursive  construct  to  an  n-ary  one,  saferec(T  >  x  :  C.e),  where  each  of  the  n 
recursive  variables  Xi  is  boxed  separately  with  type  box;\f.  (C*). 

Name  abstractions  can  also  be  used  to  express  non-strictness  of  general-purpose  ML  functors, 
which  in  turn  allows  better  static  detection  of  safe  recursion  in  certain  cases.  For  instance,  the 
recursive  module  in  Figure  7.5  provides  a  type  C.t,  which  is  defined  in  terms  of  sets  of  itself. 
(This  is  a  greatly  simplified  variant  of  the  “bootstrapped  heap”  example  from  Section  5.1.)  The 
definition  of  module  C  refers  recursively  to  the  CSet  module,  which  is  defined  by  applying  the 
MakeSet  functor  to  the  C  module.  The  only  way  we  can  be  sure  that  the  recursion  is  safe  is 
if  we  know  that  the  application  of  the  MakeSet  functor  will  not  attempt  to  apply  the  partial 
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structure  rec  C  :  ORDERED  =  struct 
datatype  t  =  . . . CSet . set .  .  . 
fun  compare  (x,y)  =  .. .CSet . compare (a, b) .. . 
end 

and  CSet  =  MakeSet(C) 

Figure  7.5;  Recursive  Module  Example  With  Non-strict  Functor  Application 


function  C.  compare,  i.e.,  that  the  MakeSet  functor  is  non-strict.  With  name  abstractions,  we 
can  instrument  the  implementation  of  MakeSet  in  order  to  assign  it  a  non-strict  type^  such  as 
VA’.boxA'(ORDERED)  SET. 

Similarly,  name  abstractions  can  be  used  to  give  more  precise  types  to  core-level  ML  functions. 
For  instance,  suppose  we  had  access  to  the  code  for  the  map  function.  By  wrapping  the  definition 
of  map  in  a  name  abstraction,  we  could  assign  the  function  the  type 


VA.  (D  ^  C)  ^  (D  list  ^  C  list) 


This  type  indicates  that  map  will  turn  a  value  of  any  arrow  type  into  a  value  of  an  arrow  type 
bearing  the  same  support,  but  will  not  apply  its  argument  in  the  process.  Given  this  type  for  map, 
we  can  write  our  recursive  module  example  involving  map  the  way  we  wanted  to  write  it  originally 
in  Section  7.1.3: 


saferec  (A  >  x 
let 

val  f  :  D 
val  g  :  D 


:  SIG. 

^  C  =  ... 

list  C  list 


map  {A}  f 


) 

The  more  precise  non-strict  type  for  map  allows  us  to  avoid  eta-expanding  map  f,  but  it  also 
requires  having  access  to  the  implementation  of  map.  Furthermore,  it  requires  us  to  modify  the 
type  of  map,  infecting  the  existing  ML  infrastructure  with  names.  It  is  therefore  important  that,  in 
the  absence  of  this  solution,  our  type  system  is  strong  enough  (thanks  to  Rule  13)  to  typecheck  at 
least  the  eta-expansion  of  map  f ,  without  requiring  changes  to  existing  ML  code.  Unfortunately, 
there  is  no  corresponding  way  to  eta-expand  the  functor  application  MakeSet  (C)  in  the  example 
from  Figure  7.5.  To  statically  ensure  that  the  recursion  in  that  example  is  safe,  it  appears  that 
one  must  have  access  to  the  implementation  of  the  MakeSet  functor  in  order  to  instrument  it  with 
name  abstractions  and  assign  it  a  more  precise  non-strict  interface. 

This  example  also  illustrates  why  it  is  useful  to  be  able  to  instantiate  a  name  abstraction  with 
a  support  instead  of  a  single  name.  In  particular,  suppose  that  f’s  type  were  D  — >  C  for  some 
non-singleton  support  S.  The  definition  of  g  would  become  map  S  f ,  which  is  only  possible  given 
the  ability  to  instantiate  map  with  a  support. 

Finally,  note  that  while  my  system  does  not  contain  any  notion  of  subtyping,  it  is  impor¬ 
tant  to  be  able  to  coerce  a  non-strict  function  into  an  ordinary  (potentially  strict)  arrow  type. 
The  coercion  from  VA.box;r(D)  — >  C  to  D  ^  C[0/A]  is  easily  encodable  within  the  language  as 
A/.Ax./(0)(box(x)). 

^For  simplicity,  I  am  ignoring  here  that  the  result  signature  SET  really  depends  on  the  type  components  of  the 
functor  argument. 
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7.2.4  Basic  Declarative  Properties 

Here  I  give  some  basic  declarative  properties  of  the  safe  recursion  language,  for  which  the  proofs 
are  by  straightforward  induction.  Note  that,  in  Part  3  of  Weakening  and  Part  1  of  Substitution, 
the  invariant  T  C  5  is  maintained  inductively  because  the  supports  of  the  premises  in  every  typing 
rule  are  supersets  of  the  support  of  the  conclusion. 

Proposition  7.2.1  (Type  Equivalence  is  an  Equivalence  Relation) 

Type  equivalence  modulo  S  is  an  equivalence  relation  on  well- formed  types. 

Proposition  7.2.2  (Weakening) 

Suppose  P  is  a  prefix  of  P',  and  S  T  S' . 

1.  If  P  h  e  :  C  [5],  then  P'  h  e  :  C  [5']. 

2.  If  P  h  Cl  =  C2  [5],  then  P'  h  Ci  =  C2  [5']. 

3.  If  r,x  :  Ci,r'  h  e  :  C  [<S]  and  P  h  Cl  =  C2  [T]  and  T  C  5,  then  r,x  :  C2,r'  b  e  :  C  [5]. 

Proposition  7.2.3  (Substitution) 

1.  If  r,x  :  C,r'  h  e  :  D  [5]  and  P  h  u  :  C  [T]  and  T  C  5,  then  T,T'  h  e[u/x]  :  D  [5]. 

2.  If  r,x  :  c,r'  h  Cl  =  C2  [5],  then  r,r'  h  Cl  =  C2  [5]. 

3.  If  r,T,r'  h  e  :  C  [5]  and  T  C  dom(r),  then  r,r'[r/T]  h  e[T/X]  :  C[r/X]  [S[T/X]]. 

4.  Ifr,T,r'hCi  =  C2  [5]  and  TCdom(r),  then  r,r'[T/T]  h  Ci[r/T]  =C2[T/X]  [S[T/X]]. 

7.2.5  Decidability  of  Typechecking 

Figure  7.6  shows  a  straightforward  typechecking  algorithm  for  the  safe  recursion  language.  The 
algorithm  takes  as  input  a  context  P,  a  term  e  and  a  support  S,  and  synthesizes  the  unique  type 
of  e  under  the  given  support.  As  with  the  typing  judgments,  I  make  implicit  assumptions  about 
the  well-formedness  of  the  algorithmic  judgments  defined  in  Figure  7.6,  e.g.,  that  all  free  names  to 
the  right  of  the  turnstile  are  bound  in  the  context. 

The  algorithm  relies  heavily  on  the  fact  that  terms  are  explicitly-typed,  and  in  particular  that  A- 
abstractions  specify  the  support  of  their  bodies.  The  problem  of  inferring  types  for  implicitly-typed 
terms  is  discussed  in  Section  7.6.1. 

Decidability  of  the  explicitly-typed  system  follows  from  the  fact  that  the  synthesis  algorithm  is 
syntax-directed,  sound  and  complete.  To  prove  soundness  of  the  synthesis  algorithm,  we  need  the 
following  technical  lemma.  Alternatively,  we  could  modify  the  second  premise  of  the  typing  rule 
for  recursive  terms  (Rule  12)  to  be  F  h  D  =  C  [5  U  ff],  in  order  to  match  the  second  premise  of  the 
corresponding  synthesis  rule.  The  lemma  just  shows  that  that  modified  version  of  the  typing  rule 
is  already  admissible. 

Lemma  7.2.4  (Division  of  Support) 

If  5  =  5i  U  ^2  and  F  h  Ci  =  C2  [5],  then  there  exists  a  type  C  such  that  F  h  C  =  Ci  [<Si]  and 
FhC^Cs  [52]. 
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Type  checking:  F  h  e  <^=  C  [5] 


r  h  e  ^  D  [5]  r  h  D  =  C  [5] 
r  h  e  ^  C  [5] 


Type  synthesis:  F  h  e  C  [5] 


X  :  C  €  F 


F  h  vi  ^  Cl  [5]  F  h  i;2  ^  Cs  [5]  F  h  v  ^  Ci  x  C2  [5] 


F  h  X  ^  C  [5]  F  h  0  ^  unit  [5] 
F,  X  :  D  h  e  ^  C  [5  U  T] 


F  h  {vi,V2)  ^  Cl  X  C2  [5] 


F  h  7ri(x)  ^  Cl  [5] 


F  h  A^x:D.e 


D  ^  C  [5] 


F  h  xi 


D 


r 


C[S]  F  h  X2  ^  D  [5]  T  CS 


F,  T  h  e  ^  C  [5] 

F  h  AT.e  ^  VT.C  [5] 

F  h  X  ^  C  [5  U  T] 


Fhxi(x2)  ^C  [5] 

F  h  X  ^  VT.C  [5] 

F  h  x(T)  ^  C[T/T]  [5] 

F  h  X  ^  boxr(C)  [5]  T  c  5 


F  h  boxr(x)  boxr(C)  [5]  F  h  unbox(x)  ^  C  [5] 

F  h  ei  ^  D  [5]  F,  X  :  D  h  62  ^  C  [5] 

F  h  let  X  =  61  in  62  C  [5] 

F,T,x  :  boxA’(C)  h6^D  [5]  F,ThD  =  C  [5UT] 

F  h  saferec(A::’  >  x  :  C.  6)  ^  C  [5] 

Figure  7.6;  Typechecking  Algorithm  for  Safe  Recursion  Language 


Proof:  By  induction  on  derivations.  The  only  interesting  cases  are  when  Ci  and  C2  carry  a 
support,  e.g.,  when  Ci  is  of  the  form  box7-i(Di).  In  this  case,  define  T  :=  {Ti  —  5i)  U  {T2  —  82). 

First  we  need  to  show  that  T  U  5*  =  U  5*.  We  will  show  this  for  i  =  1,  the  proof  for  f  =  2  is 
completely  symmetric.  We  are  given  that  T2  U  (5i  U  ^2)  =  Ti  U  (5i  U  ^2).  Thus,  72  ^  Ti  U  5i  U  ^2. 
Subtracting  ^2  from  both  sides,  T2  —  82  T  (7i  U  5i  U  ^2)  —  ^2  C  71  U  5i.  Now,  expanding  out  the 
definition  of  T,  we  have  that  T  U  5i  =  (Ti  U  5i)  U  {T2  —  82).  Then  since  72  —  ^2  C  7i  U  5i,  the 
right-hand  side  is  equal  to  Ti  U  5i . 

We  are  given  also  that  F  h  Di  =  D2  [5  U  7i].  Expanding  out  T  it  is  clear  that  8  U  T  = 
8uTiU72  =  8uTi=8u72.  Now  define  8'  :=  8i  U  T.  Clearly,  U  5^  =  5  U  T.  By  induction, 
there  exists  D  such  that  F  h  D  =  Dj  [5'].  Define  C  ;=  box7-(D).  By  Rule  18,  F  h  C  =  box7-.(Dj)  [<Si]. 


Theorem  7.2.5  (Soundness  of  Algorithm) 

If  F  h  6  ^  C  [5]  or  F  h  6  ^  C  [5],  then  F  h  6  :  C  [5]. 

Proof:  By  straightforward  induction  on  the  algorithm.  The  only  interesting  case  is  the  synthesis 
rule  for  recursive  terms.  For  that  case,  we  know  by  induction  that  F,  A,  x  :  box;r(C)  F  6  :  D  [5].  By 
Lemma  7.2.4,  since  F,  A  h  D  =  C  [5U  A],  we  know  that  there  exists  D'  such  that  F,  A  h  D  =  D'  [5] 
and  F,  A  h  D'  =  C  [A].  By  Rule  13,  F,  A,x  :  box;r(C)  h  6  :  D'  [5],  so  the  desired  result  follows  by 
Rule  12.  ■ 
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Machine  States 
Continuations  C  : 

Continuation  Frames  T  : 


0  ::=  (w;  C;  e) 

=  •  I 

=  let  X  =  •  in  e  I  saferec(<l:’  >  x  :  C.  •) 


Small-step  semantics:  Q  Q' 


(19) 


{u};C-,Tri{vi,V2))  {uj;C]Vi) 

{lo;C;  {XX.e){T))  ^  (w; C; e[T/;h]) 
X  G  dom(t(;)  u;(x)  =  v 


(w;  C;  (A^  X  :  C.  e)(x))  (a;;  C;  e[x/x]) 


(21) 


X  0  dom(u;) 


(w;  C;  box-r(t’))  {ui[x>-^v];C;x) 


(20) 


(22) 


(w;  C;  unbox(x))  i— >  {u};C]v) 


(23) 


(w;  C;  let  x  =  e'  in  e)  i— >  (w;  C  o  let  x  =  •  in  e;  e') 

(25) 


77  (24) 


{to;  C  o  let  X  =  •  in  e;  x)  1-^  (w;  C;  e[x/x]) 
A,x  ^  dom(a;) 


{lo;C;  saferec(d:’  ox  :  C.  e))  (a;[d:’  i-^x][x  i-^  ?];  C  o  saferec(d:’  ox  :  C.  •);  e) 

X  G  dom(u;)  ,  , 

- — -  (27) 

{to;  C  o  saferec(d:’  o  x  :  C.  •);v)  1—4  {oj[x  :=  x];  C;  v) 

Figure  7.7:  Dynamic  Semantics  for  Safe  Recursion  Language 


(26) 


Theorem  7.2.6  (Completeness  of  Algorithm) 

If  F  h  e  :  C  [5],  then  F  h  e  ^  C  [5]. 

Proof:  By  straightforward  induction  on  derivations.  Again,  the  only  interesting  case  is  the  typing 
rule  for  recursive  terms.  By  induction,  F,A’,x  :  box;r(C)  h  e  D'  [<S]  and  F  h  D'  =  D  [<S].  Since 
the  second  premise  of  the  typing  rule  tells  us  that  F  h  D  =  C  [A],  we  have  by  Weakening  that 
F  h  D'  =  C  [5  U  A].  Thus,  by  definition  of  synthesis,  F  h  saferec(A  0  x  :  C.  e)  C  [<S].  (It  is 
critical  here  that  the  second  premise  of  the  synthesis  rule  for  recursive  terms  use  the  modulus  5  U  A 
instead  of  just  A.)  ■ 


7.2.6  Dynamic  Semantics  and  Type  Safety 

I  formalize  the  dynamic  semantics  for  safe  recursive  terms  in  Figure  7.7,  using  an  abstract  machine 
semantics  very  similar  to  the  one  developed  in  Section  6.2.  The  main  differences  are  as  follows. 

First,  there  is  no  need  for  the  machine  state  Error  in  the  present  semantics.  Since  the  type 
system  ensures  that  a  recursive  variable  will  never  be  unboxed  before  it  has  been  backpatched,  the 
Error  state  will  never  arise.  Formally  speaking,  there  is  only  one  rule  in  the  dynamic  semantics 
for  unbox(u)  (Rule  23),  and  that  rule  only  applies  if  the  contents  of  location  v  are  defined.  If  the 
contents  of  v  are  not  defined,  the  machine  will  get  stuck,  and  the  type  safety  theorem  guarantees 
that  this  cannot  happen. 

Second,  in  order  to  connect  names  A  to  their  associated  locations,  machine  stores  co  now  contain 
mappings  for  both  locations  (represented  as  variables)  and  names.  As  in  Section  6.2,  variables  are 
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mapped  to  either  values  (u)  or  junk  (?).  Names,  in  turn,  are  mapped  to  variables.  I  will  write 
uj[A  I— >x]  to  indicate  the  extension  of  uo  with  the  mapping  of  A  to  x,  and  uj(A)  to  indicate  the 
variable  to  which  A  is  mapped  in  uj.  Thus,  in  Rule  26  for  evaluating  recursive  terms,  x  is  added  to 
the  store  with  a  binding  to  junk,  and  A  is  added  to  the  store  with  a  binding  to  x.^ 

Otherwise,  the  dynamic  semantics  of  Figure  7.7  should  be  self-explanatory. 

Before  proving  type  safety,  I  would  like  to  stress  an  important  point  about  the  practical  im¬ 
plementation  of  this  semantics.  Formally,  my  dynamic  semantics  treats  values  of  type  60x5(0)  as 
memory  locations  that  will  eventually  contain  values  of  type  C.  It  is  quite  likely,  though,  that 
values  of  type  C  {i.e.,  the  kinds  of  values  one  wants  to  define  recursively)  have  a  naturally  boxed 
representation.  For  instance,  in  the  case  of  recursive  modules,  C  will  typically  be  a  record  type, 
and  a  module  value  of  type  C  will  be  represented  as  a  pointer  to  a  record  stored  on  the  heap. 

Only  one  level  of  pointer  indirection  is  needed  to  implement  backpatching.  Thus,  a  direct 
implementation  of  my  semantics  that  represents  all  values  of  type  60x5(0)  as  pointers  to  values  of 
type  C  will  introduce  an  unnecessary  level  of  indirection  when  values  of  type  C  are  already  pointers. 
My  semantics,  however,  does  not  require  one  to  employ  such  a  naive  representation.  Indeed,  for 
types  C  with  naturally  boxed  representations,  a  realistic  implementation  should  represent  values 
of  type  60x5(0)  the  same  as  values  of  type  0  and  should  compile  the  unbox’ing  of  such  values  as 
a  no-op.  (See  Hirschowitz  et  al.  [36]  for  an  example  of  such  a  compilation  strategy.)  At  the  level 
of  the  type  system,  though,  there  is  still  an  important  semantic  distinction  to  be  made  between  0 
and  60x5(0)  that  transcends  such  implementation  details. 

To  prove  type  safety,  I  will  again  follow  the  approach  of  Section  6.2  quite  closely. 

Definition  7.2.7  (Rnn-Time  Contexts) 

A  context  F  is  run-time  if  the  only  entries  in  F  have  the  form  A  oi  x  :  6ox7-(0). 

Definition  7.2.8  (Machine  Store  Well-formedness) 

A  machine  store  ix  is  well-formed,  denoted  F  h  cj  [5],  if: 

1.  F  is  run-time  and  dom(t(;)  =  dom(r) 

2.  MA  G  F.  ijj{A)  =  X  if  and  only  if  F  =  F',  A,  x  :  6ox;r(C))  F"  for  some  0 

3.  Vx  :  6oxr(0)  G  F.  either  {(jj{x)  =  v,  where  F  h  u  :  0  [5  U  T]) 

or  (co(x)  =  ?,  and  3A  ^  S.  lu(A)  =  x) 

Like  the  machine  store  well-formedness  judgment  defined  in  Section  6.2,  the  judgment  defined 
in  Definition  7.2.8  uses  a  typing  context  F  to  describe  the  store  cu.  As  stores  now  bind  names  as 
well  as  variables,  the  second  condition  of  the  judgment  asserts  that  the  location  x  to  which  a  name 
A  is  mapped  in  the  store  is  the  same  as  the  variable  to  which  it  is  associated  (by  juxtaposition)  in 
the  typing  context.  Incidentally,  this  condition  also  guarantees  that  the  store  maps  every  name  to 
a  different  recursive  variable. 

The  store  well-formedness  judgment  differs  from  the  earlier  one  in  that  it  also  includes  a  support 
S.  The  idea  is  that  a  name  A  will  only  appear  in  the  support  <5  if  the  recursive  variable  associated 
with  that  name  has  been  backpatched.  Correspondingly,  the  third  condition  of  the  judgment  asserts 
that  for  every  location  x  in  the  store,  the  only  way  that  x  may  be  bound  to  junk  is  if  its  associated 
name  is  not  in  the  support  S. 

®In  reality,  names  can  be  erased  during  code  generation,  so  the  store  does  not  actually  have  to  create  bindings  for 
them,  but  it  is  useful  for  semantic  purposes  to  view  the  store  as  doing  so. 
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Well-formed  continuations:  F  h  C  :  C  cont  [<S] 


,  ,  rhJ?^:C^D[5]  rhC:D  cont  [5]  ,  , 

r  h  •  :  C  cont  [5]  F  h  C  o  ^  :  C  cont  [5] 

FhC:Dcont[5]  F  h  D  ^  C  [>S] 

F  h  C  :  C  cont  [5]  ^  ^ 

Well- formed  continuation  frames:  F  h  ^  :  Ci  C2  [5] 


F,x:Cihe:C2  [5]  F  =  r,  x  :  box;r(C),  F^^  F  h  D  =  C  [^] 

F  h  let  X  =  •  in  e  :  Cl  ^  C2  [5]  F  h  saferec(,F  i>  x  :  C.  •)  ;  D  ^  C  [5] 


Figure  7.8;  Well-Formed  Continuations  for  Safe  Recursion  Language 


Figure  7.8  defines  well-formedness  of  continuations  and  continuation  frames.  The  only  rule  that 
is  slightly  unusual  is  Rule  32  for  recursive  frames  saferec(d:’  i>  x  :  C.  •).  This  frame  is  not  a  binder 
for  A  or  x;  rather,  Rule  32  requires  that  <T,x  :  box;r(C)  appear  in  the  context.  This  is  a  safe 
assumption  since  saferec(<Ti>x  :  C.  •)  only  gets  pushed  on  the  stack  after  bindings  for  A  and  x  have 
been  added  to  the  store. 

We  can  now  define  a  notion  of  well-formedness  for  a  machine  state,  and  prove  type  safety.  I 
only  show  the  proof  for  the  interesting  cases,  i.e.,  recursive  terms  and  unboxing.  For  full  proofs,  I 
refer  the  reader  to  Dreyer  et  al.  [13]. 

Definition  7.2.9  (Machine  State  Well-formedness) 

A  machine  state  0  is  well-formed,  denoted  F  h  [5],  if  H  =  (ti;;C;e),  where: 

1.  F  h  (j  [5] 

2.  3C.  F  h  C  ;  C  cont  [5]  and  F  h  e  :  C  [5] 

Proposition  7.2.10  (Weakening  for  Continuations) 

Suppose  F  is  a  prefix  of  F',  and  S  C  S'. 

1.  If  F  h  C  :  C  cont  [<S],  then  F'  h  C  :  C  cont  [5']. 

2.  If  F  h  .F  :  Cl  ^  C2  [5],  then  F'  h  .T  :  Ci  ^  C2  [5']. 

Theorem  7.2.11  (Preservation) 

If  F  h  n  [5]  and  Sd  ^  O',  then  3F',5'.  F'  h  O'  [5']. 

Proof:  By  cases  on  the  second  premise. 

•  Case:  Rule  23. 

1.  By  assumption,  F  h  cu  [5],  F  h  C  :  C  cont  [5],  F  h  unbox(x)  :  C  [5],  and  u;(x)  =  v. 

2.  By  inversion  on  synthesis,  x  :  box7-(D)  G  F,  where  T  Q  S,  and  F  h  C  =  D  [<S]. 

3.  By  condition  3  of  F  h  cu  [5],  since  uj{x)  =  v,  we  have  F  h  1;  :  C  [5]. 
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•  Case:  Rule  26. 

1.  By  assumption,  F  h  w  [5],  F  h  C  :  C  cont  [5],  and  F  h  saferec(d:'  >  x  :  C.  e)  :  C  [5]. 

2.  Let  V  =  T,X,x  :  box;i'(C). 

3.  By  inversion  on  synthesis,  there  exists  D  such  that  F'  h  e  :  D  [5]  and  F'  h  D  =  C  [X]. 

4.  By  Weakening,  F'  h  C  :  C  cont  [5]. 

5.  By  Rule  32,  F'  h  C  o  saferec(d:’  i>  x  :  C.  •)  :  D  cont  [<S]. 

6.  By  Weakening  and  since  R”  0  5,  we  have  F'  h  uj\X  i— >x][xi-^?]  [<S]. 

•  Case:  Rule  27. 

1.  By  assumption,  F  h  w  [5],  F  h  C  :  C  cont  [5],  F  h  u  :  D  [5],  F  h  D  =  C  \X]  and 
F  =  F',R’,x  :  boxA’(C),F". 

2.  By  Weakening  and  Rule  13,  F  h  C  :  C  cont  [5  U  X\  and  F  h  x  :  C  [5  U  R”]. 

3.  Thus,  also  by  Weakening,  F  h  uj[x  :=  v]  [5  U  T’]. 


Lemma  7.2.12  (Canonical  Forms) 

Suppose  that  F  is  run-time  and  F  h  x  :  C  [5]. 

1.  If  C  =  unit,  then  x  is  of  the  form  (). 

2.  If  C  =  Cl  X  C2,  then  x  is  of  the  form  (xi,X2). 

3.  If  C  =  Cl  C2,  then  x  is  of  the  form  x  :  D.  e. 

4.  If  C  =  VT.D,  then  x  is  of  the  form  \X .e. 

5.  Otherwise,  x  is  a  variable  x. 

Definition  7.2.13  (Terminal  States) 

A  machine  state  0  is  terminal  if  it  has  the  form  (cx;  •;  x). 

Definition  7.2.14  (Stuck  States) 

A  machine  state  0  is  stuck  if  it  is  non-terminal  and  there  is  no  state  O'  such  that  0  O'. 

Theorem  7.2.15  (Progress) 

If  F  h  0  [5],  then  0  is  not  stuck. 

Proof:  Assume  11  =  (tx;C;  e).  By  assumption,  F  h  tx  [5].  The  proof  is  by  cases  on  C  and  e. 
•  Case:  e  =  unbox(x). 

1.  By  assumption,  F  h  C  :  C  cont  [5]  and  F  h  unbox(x)  :  C  [5]. 

2.  By  inversion  on  synthesis  and  Canonical  Forms,  x  has  the  form  x, 
where  x  :  box7-(D)  G  F  and  T  T  S  and  F  h  D  =  C  [5]. 

3.  By  condition  1  of  F  h  cx  [5],  x  €  dom(cx). 

4.  By  condition  2  of  F  h  cx  [5],  if  there  exists  X  such  that  co(X)  =  x,  then  A  G  5. 
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Types  C  :;=  •  •  •  |  ref(C)  |  cont(C) 

Terms  e  ::=  •••  |  ref(u)  |  get(r;)  |  set(r;i,r;2)  |  callccc(x.e)  j  throwc(fi, ^2) 


r  h  Cl  =  C2  [5] 
r  h  ref(Ci)  =  ref(C2)  [5] 


(33) 


rhv:C[S] 
r  h  ref(r;)  :  ref(C)  [5] 


(34) 


r  h  r;  :  ref(C)  [5]  T  h  r;i  :  ref(C)  [5]  T  h  r;2  :  C  [5] 

r  h  get(z;)  :  C  [5]  T  h  set(r;i, r;2)  :  1  [5] 


r  h  Cl  =  C2  [cS] 
r  h  cont(Ci)  =  cont(C2)  [<S] 


(37) 


r,x  :  cont(C)  h  e  :  C  [5] 
r  h  callccc(x.e)  :  C  [5]  ^  ’ 


r  h  xi  :  cont(D)  [5]  T  h  r;2  :  D  [5] 
r  h  throwc(fi,  ^2)  :  C  [<S] 


(39) 


Figure  7.9;  Static  Semantics  Extensions  for  References  and  Continuations 


5.  Then,  by  condition  3  of  T  h  w  [<S],  it  cannot  be  the  case  that  ijj{x)  =  ?. 

6.  Thus,  there  exists  v'  such  that  uj{x)  =  v' ,  and  II  makes  a  step  by  Rule  23. 

•  Case:  e  =  saferec(<T  >  x  :  C.  e').  0  makes  a  step  by  Rule  26. 

•  Case:  e  =  v,  and  C  =  C  o  saferec(T’  >  x  :  C.  •). 

1.  By  assumption,  since  C  is  well-formed,  we  have  T  =  r',T’,x  :  box;i'(C), T". 

2.  By  condition  1  of  T  h  cu  [5],  x  €  dom(u;),  so  makes  a  step  by  Rule  27. 


Corollary  7.2.16  (Type  Safety) 

If  0  h  e  :  C  [0],  then  the  evaluation  of  (e;  •;  e)  will  not  get  stuck. 

7.3  Adding  Computational  Effects 

Since  I  have  modeled  the  semantics  of  backpatching  in  terms  of  a  mutable  store,  it  is  easy  to 
incorporate  some  actual  computational  effects  into  the  language.  Figure  7.9  extends  the  syntax 
and  static  semantics  of  the  safe  recursion  language  with  mutable  state  and  continuations.  The 
primitives  for  the  former  are  ref,  get  and  set,  and  the  primitives  for  the  latter  are  callcc  and  throw, 
all  with  the  standard  typing  rules.  Ref  cells  and  continuations  are  allocated  in  the  store,  so  the 
values  of  types  ref(C)  and  cont(C)  are  variables  representing  locations  in  the  store. 

If  we  think  of  a  continuation  as  a  kind  of  function  with  no  return  type,  it  may  seem  surprising 
that  the  typing  rules  for  continuations  are  oblivious  to  names.  Moreover,  while  the  arrow  type 
Cl  — >  C2  specifies  the  support  S  required  to  call  a  function  of  that  type,  the  continuation  type 
cont(C)  does  not  specify  a  support,  and  no  support  is  required  in  order  to  throw  to  a  continuation. 
(One  can  view  cont(C)  as  always  specifying  empty  support.) 

To  see  why  a  support  is  unnecessary,  consider  what  the  machine  state  looks  like  when  we  are 
about  to  evaluate  a  callcc:  it  has  the  form  0  =  (ti;;C;  callccc(a:.  e)).  Assuming  that  II  is  well-formed 
(r  h  0  [5]),  we  know  that  T  h  C  :  C  cont  [5]  and  T  h  callccc(a:.  e)  :  C  [5].  The  current  continuation 
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X  ^  dom(t(;) 

(w;  C;  ref(ti))  i— >  (w[x  i— >  v];  C;  x) 


(40) 


X  €  domfw)  (jj(x)  =  V  ,  , 

- -  (41) 

((j;C;get(x))  (w;C;x) 

X  ^  dom(t(;) 

(cj;  C;  callccc(x.  e))  (a;[x  C];  C;  e) 


X  G  dom(u;) 


{to;  C;  set(x,  x))  i— >  {uj[x  :=  v\]C]  {)) 
X  G  dom(t(;)  (jj{x)  =  C. 


(42) 


(43) 


(cj; C; throwc(x, x))  {u:]Cx',v) 


(44) 


Figure  7.10:  Dynamic  Semantics  Extensions  for  References  and  Continuations 


is  C  and  that  is  what  callcc  will  bind  to  x  before  evaluating  e.  Then  what  is  the  “type”  of  Cl 
Although  explicit  continuations  are  not  part  of  our  language,  we  can  nonetheless  think  of  C  as  a 
function  with  argument  type  C  that,  when  applied,  may  dereference  any  of  the  recursive  variables 
associated  with  the  names  in  S.  Thus,  the  most  appropriate  arrow- like  type  for  C  would  be  C  — >  D 
for  some  return  type  D.  Under  support  5,  though,  this  arrow  type  is  equivalent  to  C  — ^  D,  or  in 
other  words  cont(C). 

Figure  7.10  gives  the  extensions  to  the  dynamic  semantics  for  mutable  state  and  continuations. 
We  extend  stores  uj  to  contain  mappings  from  locations  x  to  continuations  C.  The  rules  for  mutable 
state  are  completely  straightforward.  The  rules  for  continuations  are  also  fairly  straightforward, 
since  the  machine  state  already  makes  the  current  continuation  explicit.  Proving  type  safety  for 
these  extensions  requires  only  a  simple,  orthogonal  extension  of  the  proof  framework  from  Sec¬ 
tion  7.2.6.  The  definition  of  run-time  contexts  is  extended  to  include  variables  of  type  ref(C)  and 
cont(C),  and  the  definition  of  store  well-formedness  is  extended  as  follows; 

Definition  7.3.1  (Rnn-Time  Contexts) 

A  context  T  is  run-time  if  the  only  bindings  in  T  have  the  form  X,  x  :  box7-(C),  x  :  ref(C)  or 
X  :  cont(C). 

Definition  7.3.2  (Machine  Store  Well-formedness) 

A  store  uj  is  well-formed,  denoted  T  h  a;  [5],  if  T  h  cu  [5]  according  to  Definition  7.2.8  and  also: 

1.  Vx  :  ref(C)  G  T.  3v.  uj{x)  =  v  and  T  h  u  ;  C  [5] 

2.  Vx  :  cont(C)  G  T.  3C.  lv{x)  =  C  and  T  h  C  :  C  cont  [<S] 

7.4  Encoding  Unrestricted  Recursion 

Despite  all  the  efforts  of  the  type  system,  there  will  always  be  recursive  terms  saferec(A’  >  x  ;  C.  e) 
for  which  we  cannot  statically  determine  that  e  can  be  evaluated  without  dereferencing  x.  For  such 
cases  it  is  important  for  the  programmer  to  have  the  fallback  approach  of  using  the  unrestricted 
recursive  term  construct  rec(x  :  C.  e)  defined  in  Chapter  6,  with  the  understanding  that  dereferences 
of  X  will  be  saddled  with  a  corresponding  run-time  cost  in  order  to  guarantee  type  safety. 

The  point  of  this  section  is  to  illustrate  that  the  unrestricted  rec(x :  C.  e)  may  be  encoded  in 
terms  of  saferec(A’  i>x  :  C.  e)  if  we  extend  the  language  with  primitives  for  memoized  computations. 
The  syntax  and  static  semantics  of  this  extension  are  given  in  Figure  7.11.  First,  we  introduce  a 
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Types  C  ;:=  •••|comp5(C) 

Terms  e  ::=  •  •  •  [  delay5(e)  |  force(r') 

SuSi  =  T  =  SuS2  T  h  Cl  =  C2  [T] 
r  h  comp5^(Ci)  =  comp52(C2)  [S] 

_ _  (46) 

T  h  delay(e)  :  comp^(C)  [<S] 

T  h  z;  :  comp^(C)  [5]  T  C  5 

T  h  force(r;)  :  C  [5]  ^  ’ 

Figure  7.11:  Static  Semantics  Extensions  for  Memoized  Computations 


type  comp5(C)  of  locations  storing  memoized  computations.  A  value  of  this  type  is  essentially  a 
thunk  of  type  unit  — >  C  whose  result  is  memoized  after  the  first  application. 

The  primitive  delay5(e)  creates  a  memoized  location  x  in  the  store  bound  to  the  suspended 
term  e.  When  x  is  forced  (by  force(x)),  the  expression  e  stored  at  x  is  evaluated  to  a  value  v,  and 
then  x  is  backpatched  with  v.  During  the  evaluation  of  e,  the  location  x  is  bound  to  junk;  if  x  is 
forced  again  during  this  stage,  the  machine  raises  an  error.  Thus,  every  force  of  x  must  check  to 
see  whether  it  is  bound  to  an  expression  or  junk.  Despite  the  difference  in  operational  behavior, 
the  typing  rules  for  memoized  computations  appear  just  as  if  comp5(C),  delay5(e)  and  force(u) 

were  shorthand  for  unit  C,  A'^xiunit.  e  and  v{),  respectively.  I  use  comp(C)  and  delay(e)  as 
shorthand  for  comp0(C)  and  delay0(e),  respectively. 

We  can  now  encode  an  unrestricted  form  of  recursion.  This  construct  has  a  typing  rule  similar 
to  the  one  given  in  Section  6.2: 

r,x  :  comp(C)  h  e  :  C  [5] 

T  h  rec(a;:C.e)  :  C  [5] 

The  recursive  variable  x  is  dereferenced  by  writing  force(x)  (similar  to  fetch (x)).  The  encoding  is 
as  follows: 

rec{y:C.e)  =  force(saferec(A’ i>  x  :  comp0(C).  delay ;(^(let  y  =  unbox(x)  in  e))) 

It  is  easiest  to  understand  this  encoding  by  stepping  through  it.  First,  a  new  recursive  location 
X  is  created,  bound  to  junk.  Then,  the  delay  creates  a  new  memoized  location  2:  bound  to  the 
expression  let  y  =  unbox(x)  in  e.  Next,  the  saferec  backpatches  x  with  the  value  z  and  returns 
z.  Finally,  z  is  forced,  resulting  in  the  evaluation  of  let  y  =  unbox(x)  in  e,  which  steps  to  e[z/y]. 
Assuming  this  evaluates  to  a  value  v,  the  location  z  will  then  be  backpatched  with  v.  If  z  is 
dereferenced  during  the  evaluation  of  e[z/y]  (by  an  invocation  of  force  (y)  in  the  original  e),  then  a 
run-time  error  will  be  reported. 

Essentially,  one  can  view  the  saferec  in  this  encoding  as  tying  the  recursive  knot  on  the  mem¬ 
oized  computation,  while  the  memoization  resulting  from  the  force  is  what  actually  performs  the 
backpatching.  Observe  that  if  we  were  to  give  comp(C)  a  non-memoizing  semantics,  i.e.,  to  consider 
it  synonymous  with  unit  ^  C,  the  above  encoding  would  have  precisely  the  hxed-point  semantics 
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Machine  States  D  ::=  •  •  •  |  Error 

Continuation  Frames  F  ::=  ■  ■  ■  \  fill  x  with  • 

_ x  ^  dom(a;) _ 

(cj;  C;  delay5(e))  i— >  (cu [x  e] ;  C;  x) 

_ X  e  dom(u;)  ujjx)  =  e _  ^ 

(cj;  C;  force(x))  i— >  {uj[x  :=  ?];  C  o  fill  x  with  •;  e) 

_ x  £  dom(a;) _ 

(cj;  C  o  fill  X  with  •;  v)  (^[x  :=  v];C;  v) 

X  €  dom(L(j)  uj(x)  =  ? 

(ti;;C  o  force(»);x)  Error  ' 

r  h  X  :  comp(C)  [5] 
r  h  fill  X  with  •  :  C  ^  C  [5]  ^  ’ 

Figure  7.12:  Dynamic  Semantics  Extensions  for  Memoized  Computations 


of  recursion.  Memoization  ensures  that  the  effects  in  e  only  happen  once,  at  the  first  force  of  the 
recursive  computation. 

The  dynamic  semantics  for  this  extension  is  given  in  Figure  7.12.  To  evaluate  delay5(e),  we 
create  a  new  memoized  location  in  the  store  and  bind  e  to  it  (Rule  48).  To  evaluate  force(x), 
we  proceed  to  evaluate  the  term  e  to  which  x  is  bound,  pushing  on  the  continuation  stack  a 
memoization  frame  (fill  x  with  •)  to  remind  us  that  the  result  of  evaluating  e  should  be  memoized 
at  X  (Rules  49  and  50).  If  x  is  instead  bound  to  junk,  then  we  must  be  in  the  middle  of  evaluating 
another  force(x),  so  we  step  to  an  Error  state  which  halts  the  program  (Rule  51). 

Extending  the  type  safety  proof  to  handle  memoized  computations  is  straightforward.  Con¬ 
tinuation  frame  well-formedness  is  extended  with  Rule  52  for  memoization  frames.  We  must  also 
update  the  definition  of  run-time  contexts  to  include  memoized  location  bindings,  well-formed  and 
terminal  states  to  include  Error,  and  store  well-formedness  to  account  for  memoized  locations: 

Definition  7.4.1  (Rnn-Time  Contexts) 

A  context  F  is  run-time  if  the  only  bindings  in  F  take  the  form  X,  x  :  box-7-(C),  x  :  ref(C), 
X  :  cont(C)  or  x  :  comp^(C). 

Definition  7.4.2  (Machine  State  Well-formedness) 

A  machine  state  D  is  well-formed  if  either  D  =  Error  or  D  is  well-formed  according  to  Definition  7.2.9. 
Definition  7.4.3  (Terminal  States) 

A  machine  state  D  is  terminal  if  either  D  =  Error  or  D  is  terminal  according  to  Definition  7.2.13. 
Definition  7.4.4  (Store  Well-formedness) 

A  store  w  is  well-formed,  denoted  F  h  u;  [5],  if  F  h  u;  [5]  according  to  Definition  7.3.2  and  also: 

•  Vx  :  comp.2'(C)  G  F.  either  (jo{x)  =  ?,  or  u;(x)  =  e  and  F  h  e  :  C  [<S  U  T] 
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7.5  Related  Work 

Safe  Recursion  Boudol  [5]  proposes  a  type  system  for  safe  recursion  that,  like  mine,  employs  a 
backpatching  semantics.  Boudol’s  system  tracks  the  degrees  to  which  expressions  depend  on  their 
free  variables,  where  the  degree  to  which  e  depends  on  x  is  1  if  x  appears  in  a  guarded  position 
in  e  {i.e.,  under  an  unapplied  A-abstraction),  and  0  otherwise.  What  I  call  the  “support”  of  an 
expression  corresponds  in  Boudol’s  system  to  the  set  of  variables  on  which  the  expression  depends 
with  degree  0.  Thus,  while  there  is  no  distinction  between  recursive  and  ordinary  variables  in 
Boudol’s  system,  his  equivalent  of  saferec(fk’  >  x  :  C.  e)  ensures  that  the  evaluation  of  e  will  not 
dereference  x  by  requiring  that  e  depend  on  x  with  degree  1. 

In  my  system  an  arrow  type  indicates  the  recursive  variables  that  may  be  dereferenced  when  a 
function  of  that  type  is  applied.  An  arrow  type  in  Boudol’s  system  indicates  the  degree  to  which  the 
body  of  a  function  depends  on  its  argument.  Thus,  D  C  and  D  — !->  C  classify  functions  that 
are  strict  and  non-strict  in  their  arguments,  respectively.  As  I  discussed  in  Section  7.2.3,  the  ability 
to  identify  non-strict  functions  is  especially  important  for  purposes  of  separate  compilation.  For 
example,  in  order  to  typecheck  the  separate  compilation  scenario  from  Figure  5.11,  it  is  necessary 
to  know  that  the  separately-compiled  functors  F_Expr  and  F_Bind  are  non-strict. 

In  contrast  to  my  system,  which  requires  the  code  from  Figure  5.11  to  be  rewritten  as  shown 
in  Figure  7.4,  Boudol’s  system  can  typecheck  the  code  in  Figure  5.11  essentially  as  is.  The  reason 
is  that  function  applications  of  the  form  /(x)  (where  the  argument  is  a  variable)  are  treated  as  a 
special  case  in  his  semantics:  while  the  expression  “x”  depends  on  the  variable  x  with  degree  0, 
the  expression  “/(x)”  merely  passes  x  to  /  without  dereferencing  it.  This  implies  that  ordinary 
A-bound  variables  may  be  instantiated  at  run  time  with  recursive  variables.  Thus,  viewed  in  terms 
of  my  semantics,  Boudol’s  system  treats  all  variables  as  implicitly  having  box  type. 

The  simplicity  of  Boudol’s  system  is  achieved  at  the  expense  of  being  rather  conservative.  In 
particular,  a  function  application  /(e)  is  considered  to  depend  on  all  the  free  variables  of  /  with 
degree  0.  Suppose  that  /  is  a  curried  function  Xy.Xz.e' ,  where  e'  dereferences  a  recursive  variable  x. 
In  Boudol’s  system,  even  a  single  application  of  /  will  be  considered  to  depend  on  x  with  degree  0 
and  thus  cannot  appear  unguarded  in  the  recursive  term  defining  x. 

To  address  the  limitations  of  Boudol’s  system,  Hirschowitz  and  Leroy  [35]  propose  a  general¬ 
ization  of  it,  which  they  use  as  the  target  language  for  compiling  a  call- by- value  mixin  module 
calculus.  Specifically,  they  extend  Boudol’s  notion  of  degrees  to  be  arbitrary  integers:  the  degree 
to  which  e  depends  on  x  becomes,  roughly,  the  number  of  unapplied  A- abstractions  under  which  x 
appears  in  e.  Thus,  continuing  the  above  example,  the  function  Xy.Xz.e'  would  depend  on  x  with 
degree  2,  so  instantiating  the  first  argument  would  only  decrement  that  degree  to  1,  not  0. 

Nevertheless,  Hirschowitz  and  Leroy’s  system  still  suffers  from  a  paucity  of  types.  Consider 
the  same  curried  function  example,  except  where  we  let-bind  Xy.Xz.e'  first  instead  of  applying  it 
directly:  let  /  =  Xy.Xz.e'  in  /(e).  The  most  precise  degree-based  type  one  can  give  to  /  when 
typing  the  body  of  the  let  is  Ci  C2  C3.  This  type  tells  us  nothing  about  the  degree  to 
which  /  depends  on  the  recursive  variable  x  dereferenced  by  e' .  Thus,  Hirschowitz  and  Leroy’s 
system  must  conservatively  assume  that  /(e)  may  dereference  x.  In  contrast,  my  type  system  can 

assign  /  a  more  expressive  type  such  as  Ci  C2  C3,  which  would  allow  its  first  argument 
(but  not  its  second)  to  be  instantiated  under  the  empty  support. 

I  believe  the  let  expression  above  is  representative  of  code  that  one  might  want  to  write  in  the 
body  of  a  recursive  module,  which  suggests  that  my  name-based  approach  is  a  more  appropriate 
foundation  for  recursive  modules.  However,  the  weaknesses  of  the  degree-based  approaches  are 
not  necessarily  problematic  in  the  particular  applications  for  which  they  were  developed.  For 
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the  purpose  of  compiling  mixin  modules,  the  primary  feature  required  of  Hirschowitz  and  Leroy’s 
target  language  is  the  ability  to  link  mutually  recursive  A-abstractions  that  have  been  compiled 
separately.  As  I  have  illustrated  in  Section  7.2.3,  my  language  supports  this  feature  as  well,  via 
name  abstractions. 


Weak  Polymorphism  and  Effect  Systems  There  seems  to  be  an  analogy  between  the  ap¬ 
proaches  discussed  here  for  tracking  safe  recursion  and  the  work  on  combining  polymorphism  and 
effects  in  the  early  days  of  ML.  Boudol’s  0-1  distinction  is  reminiscent  of  Tofte’s  distinction  between 
imperative  and  applicative  type  variables  [78].  Hirschowitz  and  Leroy’s  generalization  of  Boudol  is 
similar  to  the  idea  of  weak  polymorphism  [23]  (implemented  by  MacQueen  in  earlier  versions  of  the 
SML/NJ  compiler),  wherein  a  type  variable  a  carries  a  numeric  “strength”  representing,  roughly, 
the  number  of  function  applications  required  before  a  ref  cell  is  created  storing  a  value  of  type  a. 
My  system  has  ties  to  effect  systems  in  the  style  of  Talpin  and  Jouvelot  [76],  in  which  an  arrow 
type  indicates  the  set  of  effects  that  may  occur  when  a  function  of  that  type  is  applied.  For  safe 
recursion,  the  effect  in  question  is  the  dereferencing  of  an  undefined  recursive  variable. 

A  common  criticism  leveled  at  both  effect  systems  and  weak  polymorphism  is  that  functional 
and  imperative  implementations  of  a  polymorphic  function  have  different  types,  and  it  is  impossible 
to  know  which  type  to  expect  when  designing  a  specification  for  a  module  separate  from  its  imple¬ 
mentation  [82].  To  a  large  extent,  this  criticism  does  not  apply  to  my  type  system:  names  infect 
types  within  recursive  modules,  but  the  external  interface  of  a  module  will  be  the  same  regardless 
of  whether  or  not  the  module  is  implemented  recursively.  To  ensure  that  certain  recursive  modules 
(like  the  one  in  Figure  7.5)  are  safe,  however,  one  needs  to  observe  that  a  general-purpose  functor 
(like  the  MakeSet  functor)  is  non-strict,  and  it  is  debatable  whether  the  (non-)strictness  of  such  a 
functor  should  be  reflected  in  its  specification.  Choosing  not  to  expose  strictness  information  in 
the  specification  of  a  functor  imposes  fundamental  limitations  on  how  the  functor  can  be  used,  not 
just  in  my  system,  but  in  any  type  system  for  safe  recursion. 


Strictness  Analysis  One  can  think  of  static  detection  of  safe  recursion  as  a  kind  of  non-strictness 
analysis,  in  contrast  to  the  well-known  problem  of  strictness  analysis  [1].  Both  problems  are 
concerned  with  identifying  whether  an  expression,  such  as  the  body  of  a  function,  will  access 
the  value  of  a  particular  variable  when  evaluated.  Strictness  analysis,  however,  is  used  as  an 
optimization  technique  for  lazy  languages,  in  which  any  function  may  be  conservatively  classified 
as  non-strict.  In  call-by-value  languages,  on  the  other  hand,  functions  are  strict  by  default — 
observing  that  a  function  is  non-strict  requires  us  to  explicitly  treat  its  argument  as  boxed  and  to 
show  that  applying  the  function  will  not  unbox  it.  It  is  thus  unclear  how  techniques  from  strictness 
analysis  might  be  applied  to  the  safe  recursion  problem. 


Names  The  idea  of  using  names  in  my  type  system  is  inspired  by  Nanevski’s  work  on  using  a 
modal  logic  with  names  to  model  a  “metaprogramming”  language  for  symbolic  computation  [57]. 
(His  use  of  names  was  in  turn  inspired  by  Pitts  and  Gabbay’s  FreshML  [64].)  Nanevski  uses  names 
to  represent  undefined  symbols  appearing  inside  expressions  of  a  modal  □  type.  These  expressions 
can  be  viewed  as  pieces  of  uncompiled  syntax  whose  free  names  must  be  defined  before  they  can 
be  compiled. 

My  use  of  names  is  conceptually  closer  to  Nanevski’s  more  recent  work  on  using  names  to  model 
control  effects  for  which  there  is  a  notion  of  handling  [58] .  One  can  think  of  the  dereferencing  of  a 
recursive  variable  as  an  effect  that  is  in  some  sense  “handled”  by  the  backpatching  of  the  variable. 
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Formally,  though,  Nanevski’s  system  is  quite  different,  not  least  in  that  it  does  not  employ  any 
judgment  of  type  equivalence  modulo  a  support,  which  plays  a  critical  role  in  my  system. 

Monadic  Recursion  There  has  been  considerable  work  recently  on  adding  effectful  recursion  to 
Haskell.  Since  effects  in  Haskell  are  isolated  in  monadic  computations,  adding  a  form  of  recursion 
over  effectful  expressions  requires  an  understanding  of  how  recursion  interacts  with  monads.  Erkok 
and  Launchbury  [17]  propose  a  monadic  fixed-point  construct  mfix  for  defining  recursive  computa¬ 
tions  in  monads  that  satisfy  a  certain  set  of  axioms.  They  later  show  how  to  use  mfix  to  define  a 
recursive  form  of  Haskell’s  do  construct  [18].  Friedman  and  Sabry  [21]  argue  that  the  backpatch- 
ing  semantics  of  recursion  is  fundamentally  stateful,  and  thus  defining  a  recursive  computation  in 
a  given  monad  requires  the  monad  to  be  combined  with  a  state  monad.  This  approach  allows 
recursion  in  monads  that  do  not  obey  the  Erkok-Launchbury  axioms,  such  as  the  continuation 
monad. 

The  primary  goal  of  my  type  system  is  to  statically  ensure  safe  recursion  in  an  impure  call-by- 
value  setting,  and  thus  the  work  on  recursive  monadic  computations  for  Haskell  (which  avoids  any 
static  analysis)  is  largely  orthogonal  to  mine.  Nevertheless,  the  dynamic  semantics  of  my  language 
borrows  from  the  work  of  Moggi  and  Sabry  [54],  who  give  an  operational  semantics  for  the  monadic 
metalanguage  extended  with  the  Friedman-Sabry  mfix. 

7.6  Directions  for  Future  Work 

In  this  chapter,  I  have  studied  the  safe  recursion  problem  at  the  level  of  the  simply-typed  A-calculus. 
In  order  to  incorporate  the  ideas  from  this  calculus  into  a  viable  recursive  module  extension  to  ML, 
there  are  at  least  two  significant  issues  that  must  be  broached:  (1)  Do  names  and  supports  change 
the  meaning  of  “principal”  type  schemes  for  ML  terms?  and  (2)  How  should  names  be  integrated 
into  the  ML  module  system?  The  first  issue  is  clearly  important,  since  type  inference  is  one  of 
ML’s  most  notable  features.  The  second  issue  is  important  as  well,  since  the  main  motivation  for 
safe  recursion  is  to  support  more  efficient  recursive  modules,  not  terms.  I  discuss  these  issues  in 
Sections  7.6.1  and  7.6.2,  respectively. 

7.6.1  Names  and  Type  Inference 

The  safe  recursion  language  developed  in  this  chapter  requires  explicit  type  and  support  annotations 
on  A-abstractions.  In  contrast,  the  ML  language  does  not  require  the  programmer  to  annotate 
function  arguments  (or  any  other  variables)  with  their  types;  it  infers  the  most  general  type  scheme 
for  a  function  argument  by  looking  at  how  it  is  used  in  the  function  body.  Is  there  a  way  to  adapt 
Damas-Milner  type  inference  [8]  to  infer  principal  type  schemes  in  the  presence  of  names? 

Let  us  view  inference  as  a  procedure  that  takes  an  implicitly-typed  external-language  (EL)  pro¬ 
gram  and  translates  it  into  an  explicitly-typed  internal-language  (IL)  program.  The  main  difficulty 
is  that,  if  EL  functions  are  not  annotated  with  supports,  there  may  be  several  incomparable  ways 
to  translate  them.  To  take  a  simple  example,  say  we  are  given  a  function  f  with  input  type  C  and 

output  type  D.  If  the  body  of  f  is  well-typed  under  the  empty  support,  then  we  can  annotate  f 

0  S 

so  that  it  has  the  type  C  — >  D,  but  we  can  also  annotate  it  to  have  the  type  C  — >  D  for  any 

well-formed  support  S. 

Name  abstractions  provide  a  potential  solution  to  this  problem.  If  the  support  of  an  arrow 
type  is  under-specified,  a  name  abstraction  can  be  used  to  generalize  it.  For  example,  if  f  has  the 
form  Xx.e,  then  we  can  generalize  f ’s  type  to  VT.C  — >  D  by  enclosing  f  in  a  name  abstraction 
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{i.e.,  XX.X^x :  C.  e).  This  type  scheme  for  f  is  principal  in  the  sense  that  any  valid  type  for  f  may 
be  produced  by  instantiating  X  in  the  type  scheme  with  a  particular  support.  As  with  ML-style 
let-polymorphism,  it  is  important  that  we  only  generalize  the  types  of  terms  that  are  valuable 
{i.e.,  pure  and  terminating) — otherwise,  generalization  could  change  the  meaning  of  a  term  by 
suspending  its  effects. 

While  the  generalized  type  for  f  is  straightforward  to  understand,  it  is  easy  to  construct  terms 
for  which  the  principal  type  scheme,  or  even  the  existence  of  one,  is  far  from  obvious.  Consider  a 
function  h,  defined  as  fn  (f,g)  =>  fn  x  =>  f(fn  y  =>  x  +  g(x)  +  g(y)).  By  simple  inference 
reasoning,  the  use  of  addition  implies  that,  modulo  supports,  x  has  type  int,  g  has  type  int  ^  int, 
and  f  has  type  (int  — >  int)  ^  int.  One  might  therefore  imagine  inferring  the  following  name- 
polymorphic  type  scheme  for  h: 


V<Ti,  A2,  A3.(((int  int)  int)  x  (int  int))  (int  int) 

The  support  on  g’s  arrow  type  and  the  support  on  f ’s  argument’s  arrow  type  are  matched  up  (Ai); 
the  support  on  the  result  arrow  type  equals  the  support  on  f’s  arrow  type  (A2);  and,  since  the 
body  of  h  is  a  value,  the  support  on  h’s  arrow  type  can  be  anything  (A3). 

Unfortunately,  as  complicated  as  it  already  is,  this  type  scheme  is  not  principal.  In  particular, 
assuming  the  existence  of  a  name  A,  the  following  is  a  valid  type  assignment  for  h  which  is  not  an 
instance  of  the  above  type  scheme; 

(((int  — >  int)  — >  int)  x  (int  — >  mt))  — >  (int  — >  int) 

The  point  here  is  that  it  is  fine  for  the  support  on  g’s  arrow  to  differ  from  the  support  on  f’s 
argument’s  arrow,  so  long  as  the  symmetric  difference  of  the  two  supports  is  included  in  the  result 
arrow.  Correspondingly,  here  is  a  type  scheme  for  h  that  I  conjecture  (but  do  not  know)  is  principal; 

VAi,  d;2,  A3,  A4,  A5,  d:6.(((int  — >  int)  — ^  int)  x  (int  — >  mt;))  — ^  (int  — ^  int) 

The  supports  on  g’s  arrow  and  f’s  argument’s  arrow  are  permitted  to  differ  ({A2,  A4}),  and  the 
result  arrow  is  allowed  to  contain  arbitrary  extra  names  (A5).  The  type  assignment  for  h  given  above 
can  be  produced  by  instantiating  the  principal  type  scheme  with  A4  =  A  and  Aj  =  0  otherwise. 

Determining  whether  principal  type  schemes  exist  in  general  in  the  presence  of  names  is  a  key 
direction  for  future  work.  However,  the  possibly  principal  type  scheme  for  h  is  a  classic  example 
of  why  people  tend  to  be  wary  of  effect  inference.  The  inferred  type  is  huge,  hard  to  understand, 
and  probably  much  more  general  than  necessary.  In  fact,  it  is  quite  possible  that  the  programmer 
will  only  use  h  at  instances  where  all  the  Aj  are  set  to  0.  I  suspect  therefore  that,  even  if  principal 
type  schemes  exist  in  the  presence  of  names,  it  may  nevertheless  be  a  good  idea  to  assume  that 
A-abstractions  are  annotated  with  the  empty  support  unless  specified  otherwise,  and  to  treat  name 
abstraction  and  instantiation  as  explicit  programmer-level  operations. 

7.6.2  Names  and  Modules 

Another  key  direction  for  future  work  is  to  scale  the  type  system  presented  in  this  chapter  to  the 
level  of  modules.  In  the  process  of  preparing  this  thesis,  I  spent  some  time  exploring  this  direction. 
I  sketched  the  semantics  and  meta-theory  of  a  safe  recursive  module  construct,  as  an  extension  to 
the  DCH  language  [12]  (discussed  in  Section  2.3).  The  extension  was  rather  complex  and  required 
global  changes  to  the  DCH  type  system.  Some  of  this  complexity  appears  to  be  unavoidable,  but 


162 


CHAPTER  7.  SAFE  RECURSION 


I  believe  that  some  of  it  was  also  due  to  limitations  of  the  DCH  formalism.  In  this  section,  I  will 
describe  at  a  high  level  some  of  the  issues  that  arise  in  building  a  safe  recursive  module  extension 
to  the  type  system  of  Chapters  3  and  4,  and  how  we  may  deal  with  them.  Working  out  the  full 
details  of  such  an  extension  remains  important  and  non-trivial  future  work. 

In  order  to  scale  the  work  of  this  chapter  to  the  level  of  modules  with  type  components,  the  first 
thing  we  must  do  is  integrate  names  and  supports  into  the  core  language  of  Chapter  3.  This  requires 
us  to  adapt  the  notion  of  type  equivalence  modulo  a  support  to  account  for  type  constructors  of 
higher  kinds  and  singleton  kinds.  I  believe  this  step  is  relatively  straightforward,  but  it  involves 
a  global  change  to  the  language,  which  in  turn  necessitates  a  reproof  of  the  entire  Stone-Harper 
meta-theory! 

The  global  change  is  essentially  to  add  a  support  [5]  to  the  end  of  every  core-language  judgment. 
The  support  of  a  judgment  indicates  the  set  of  names  that  the  derivation  of  the  judgment  can  simply 
ignore.  Thus,  aside  from  the  typing  and  type  equivalence  rules  given  in  this  chapter,  all  other  rules 
will  have  the  same  support  S  in  the  premises  as  in  the  conclusion.  Note  that,  because  of  singletons, 
supports  must  be  added  even  to  the  well-formedness  judgments  for  constructors  and  kinds.  For 
instance,  a  constructor  C  has  kind  S(D)  if  and  only  if  C  is  equivalent  to  D  at  kind  T.  If  the  two 
types  are  only  equivalent  modulo  support  S,  then  C  will  only  have  kind  S(D)  under  support  S. 
Consequently,  since  the  well-formedness  of  a  singleton  kind  5(C)  depends  on  the  well-formedness 
of  C,  S(C)  will  only  be  well-formed  under  whatever  support  C  requires  to  be  well-formed. 

The  next  step  is  to  integrate  names  and  supports  into  the  module  language.  This  may  be  done 
in  an  analogous  way,  adding  supports  to  the  end  of  every  module  and  signature  judgment  form,  with 
the  interpretation  that  the  names  in  the  support  may  be  ignored  in  the  derivation  of  the  judgment. 
On  the  surface,  this  seems  straightforward,  as  the  effect  of  “static  purity”  or  “separability”  tracked 
by  the  module  system  is  completely  orthogonal  to  the  effect  of  dereferencing  a  recursive  variable. 

We  must  introduce  a  saferec(T’  >X  :  S.  M)  module  construct,  as  well  as  a  box7-(S)  signature  for 
classifying  recursive  module  variables.  Functors  and  functor  signatures  must  be  annotated  with 
the  support  of  their  bodies.  The  rules  for  these  constructs  will  combine  their  typing  rules  from 
Chapter  4  with  the  rules  for  their  term-level  counterparts  given  in  this  chapter.  For  example,  a 
natural  typing  rule  for  total  functors  would  be; 

F,  X:S'  h  M  :p  S"  [5  U  T] 

F  h  At^tX:S'.M  :p  H^^XiShS"  [5] 

This  is  very  similar  to  the  typing  rule  for  term-level  A-abstractions  (Rule  5  of  this  chapter). 

On  closer  inspection,  however,  an  interesting  problem  arises  with  regard  to  the  following  ques¬ 
tion:  what  is  the  static  part  of  a  functor  or  functor  signature  bearing  support  T,  i.e.,  how  should  we 
define  Fst(A^tX:S.M)  and  Fst(n^^X:Si.S2)?  Since  A’s  at  the  constructor  level  do  not  have  supports, 
the  only  obvious  answer  is  to  ignore  the  support  T,  defining  Fst(A^tX:S.M)  as  AX'^:Fst(S).Fst(M) 
and  Fst(n^tX:Si.S2)  as  nX":Fst(Si).Fst(S2). 

To  illustrate  the  problem  with  this  answer,  consider  the  functor  F  =  A(^t_  :l.[int  int], 
which  takes  unit  argument  and  returns  a  module  with  a  single  type  component,  int  — >  int.  By  the 
typing  rule  for  functors  given  above,  F  can  be  assigned  the  signature  S  =  :I.|S(int  int)] 

under  the  empty  support.  The  point  here  is  that  the  body  is  typechecked  under  the  extended 
support  {A},  and  under  that  support  the  type  int  — >  int  can  be  given  the  kind  S(int  — >  int). 
Unfortunately,  while  F  may  have  signature  S  under  the  empty  support,  Fst(F)  =  A_  :l.int  — >  int 

does  not  have  kind  Fst(S)  =  n_  :I.S(int  — ^  int)  under  the  empty  support.  This  breaks  an 
important  hygienic  property  of  the  Fst  function. 
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The  problem  is  that  the  functor  typing  rule  allows  the  well-formedness  of  the  static  part  of 
F’s  body  to  depend  on  support  X,  whereas  the  body  of  Fst(F)  may  not  depend  on  that  support. 
To  address  this  problem,  we  must  either  redefine  the  Fst  function  or  change  the  module  typing 
judgment.  It  is  not  clear  how  to  redefine  Fst  without  first  changing  the  core-language  type  system 
so  that  constructor-level  functions  may  bear  supports.  While  it  is  possible  such  an  approach  could 
work,  it  would  require  a  more  significant  and  less  obvious  change  to  the  equational  theory  of  types 
than  what  I  described  above. 

An  easier  approach,  I  believe,  is  to  rethink  the  module  typing  judgment  F  h  M  S  [5].  Instead 
of  ignoring  the  names  in  S  in  the  whole  typing  derivation  for  M,  suppose  that  we  only  ignore  them 
when  typechecking  the  dynamic  part  of  M  and  that  we  typecheck  the  static  part  of  M  under  empty 
support.  For  instance,  the  typing  rules  for  atomic  type  and  term  modules  might  differ  as  follows: 

F  h  C  :  K  [0]  F  h  e  :  C  [5] 

F  h  [C]  :p  [K]  [5]  F  h  [e]  :p  [Cl  [5] 

The  first  rule  would  prevent  the  body  of  the  functor  F,  [int  — >  int],  from  being  assigned  the 

signature  [S(int  — ^  int)].  More  generally,  the  Fst  function  would  regain  the  property  that,  if  M 
has  signature  S  under  support  S,  then  Fst(M)  has  kind  Fst(S)  under  the  empty  support. 

To  validate  this  re- interpretation  of  the  module  typing  judgment,  we  also  have  to  change  the 
subsumption  rule: 

F  h  M  S'  [5]  F  h  S'  <  S  [5] 

F  h  M  S  [5] 

This  rule  is  problematic  because,  for  example,  it  allows  a  module  of  signature  |S(C)|  to  be  coerced 
to  the  signature  |S(D)|,  where  C  and  D  are  only  equivalent  modulo  support  S.  An  easy  way  to 
remedy  this  problem  is  to  add  to  the  subsumption  rule  an  extra  premise,  F  h  Fst(S')  <  Fst(S)  [0], 
requiring  that  the  static  part  of  S'  match  the  static  part  of  S  under  the  empty  support.® 

Aside  from  this  issue,  I  believe  the  integration  of  names  and  supports  into  my  module  type 
system  should  be  fairly  straightforward.  It  should  be  clear  from  this  discussion,  though,  that 
supporting  static  detection  of  safe  recursion  involves  a  non-trivial,  pervasive  extension  to  the  in¬ 
frastructure  and  meta-theory  of  the  language.  It  is  not  so  clear  whether  the  added  benefit  such  an 
extension  offers  in  terms  of  recursive  module  efficiency  and  reliability  is  worth  the  added  complexity. 


®In  extending  DCH,  which  did  not  have  any  notion  of  a  Fst  function,  it  was  necessary  to  modify  the  signature 
subtyping  judgment  so  that  F  h  Si  <  S2  [<S]  only  ignored  the  names  in  S  when  matching  the  dynamic  parts  of  Si 
against  those  of  S2. 
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Evolving  the  ML  Module  System 


Chapter  8 


Evolving 


the  ML  Internal  Language 


Parts  I  and  II  of  this  thesis  have  been  devoted  to  achieving  a  clearer  understanding  of  the  ML  module 
system  and  of  the  problem  of  extending  ML  with  recursive  modules.  Based  on  this  understanding, 
I  described  in  Section  2.2  a  proposal  for  unifying  the  existing  variants  of  the  ML  module  system, 
and  in  Section  5.4  a  proposal  for  extending  ML  with  recursive  modules.  It  is  time  to  make  those 
proposals  concrete. 

In  this  and  the  next  chapter,  I  will  use  the  Harper-Stone  interpretation  of  Standard  ML  [33] 
as  the  framework  and  starting  point  for  defining  a  new,  evolved  dialect  of  ML.  As  described  in 
Section  2.2.3,  the  Harper-Stone  framework  (hereafter,  HS)  defines  SML  by  translating  (or  “elabo¬ 
rating”)  the  programmer-level  “external”  language  (EL)  into  an  “internal”  language  (IL),  which  is 
defined  by  a  type  system.  Following  their  approach,  I  will  formalize  my  internal  language  in  the 
present  chapter  and  my  external  language  in  the  next  chapter. 

My  internal  language  is  based  very  closely  on  the  module  type  system  I  developed  in  Chapters  3 
and  4  and  extended  in  Chapter  6,  which  I  will  refer  to  as  the  “simplified  IL.”  The  differences  between 
the  simplified  and  actual  IL’s  are  mostly  superficial.  For  instance,  to  facilitate  the  understanding 
of  my  new  design  by  one  who  is  already  familiar  with  HS,  I  have  chosen  in  most  cases  to  use  the 
HS  conventions  for  naming  metavariables  rather  than  my  own  naming  conventions  from  earlier  in 
the  thesis  {e.g.,  I  use  the  metavariables  mod  and  sig  here  instead  of  M  and  S  to  stand  for  modules 
and  signatures). 

There  are  a  few  non-trivial  differences,  however,  which  I  discuss  in  Section  8.1.  For  those  familiar 
with  the  details  of  Harper  and  Stone’s  formalism,  I  also  discuss  the  ways  in  which  my  IL  differs 
from  theirs.  Sections  8.2,  8.3  and  8.4  present  the  syntax,  static  semantics  and  dynamic  semantics 
of  my  IL,  respectively.  As  the  IL  is  for  the  most  part  very  similar  to  the  simplified  IL,  I  do  not  give 
an  explicit  typechecking  algorithm  or  repeat  the  meta-theoretic  development  of  Chapters  3,  4  and 
6.  Adapting  them  to  the  actual  IL  is  completely  straightforward. 


8.1  Overview 

8.1.1  Differences  from  the  Simplified  IL 

Modulo  naming  conventions,  the  only  substantive  differences  between  the  simplified  and  actual  IL’s 
are  as  follows. 

First,  instead  of  unlabeled  pair  kinds  and  pair  signatures,  whose  components  are  indexed  by 
position  (tti  or  7r2),  the  actual  IL  provides  n-ary  labeled  record  kinds  and  record  signatures,  whose 
components  are  indexed  by  label.  The  generalization  from  pairs  to  n-ary  records  is  a  common. 
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straightforward  one.  The  generalization  to  labeled  indexing  is  also  straightforward. 

It  is  important  to  understand  that  the  labels  on  a  record’s  components  are  not  alpha-convertible. 
Each  component  of  a  record  constructor  or  module  has  attached  to  it  a  label,  by  which  it  is  referred 
to  externally,  and  a  variable,  by  which  it  is  referred  to  internally,  i.e.,  by  the  other  components 
defined  after  it  in  the  record.  Records  are  identified  up  to  alpha-renaming  of  their  bound  variables, 
but  not  their  labels. 

As  the  subtyping  relations  on  record  kinds  and  signatures  do  not  permit  reordering  or  dropping 
of  components,  there  is  no  significant  semantic  difference  between  these  record  kinds/signatures  and 
the  pair  kinds/signatures  of  the  simplified  IL.  The  only  differences  are  in  the  number  of  components 
in  a  record  and  how  they  are  indexed.  I  use  record  kinds/signatures  here  instead  of  pairs  primarily 
in  order  to  model  ML  structure’s  more  faithfully  and  to  hew  closer  to  Harper-Stone. 

Second,  whereas  in  the  simplihed  IL  I  modeled  type  and  val  bindings  in  structures  as  bindings 
of  atomic  modules  [C]  and  [e],  the  actual  IL  allows  one  to  bind  types  and  terms  directly  as  sub¬ 
components  of  record  modules  without  encasing  them  in  their  own  atomic  modules.  Again,  this  is 
not  a  matter  of  semantic  importance,  merely  one  of  convenience. 

Third,  the  actual  IL  provides  a  richer  set  of  base  types  than  the  simplified  IL.  These  include 
sum  types,  n-ary  record  types,  mutable  reference  types,  and  an  extensible  sum  type  Tagged.  The 
introduction  and  elimination  forms  for  sums,  records,  and  refs  are  standard.  The  type  Tagged 
models  the  ML  type  of  exceptions,  exn.  A  value  of  type  Tagged  is  a  pair  of  a  value  val  of  type 
con  and  a  “tag”  of  type  con  Tag.  An  ML  exception  binding  like  exception  E  of  int  results  in 
the  creation  of  a  new  tag  of  type  int  Tag  by  invoking  the  primitive  IL  construct  new_tag[int]. 
Values  val  of  type  Tagged  may  be  pattern-matched  against  tags  of  type  con  Tag  by  the  primitive 
IL  construct  \ftagof  val  \s  val'  then  val"  else  exp.  This  checks  whether  val'  is  the  tag  of  val:  if  so,  it 
passes  the  underlying  value  of  val  to  the  function  val";  if  not,  it  proceeds  to  evaluate  the  term  exp'. 

8.1.2  Differences  from  the  Harper-Stone  IL 

The  Harper-Stone  IL  is  based  on  the  Harper-Lillibridge  (HL)  type  system  [28]  but  only  supports 
second-class  modules.  Thus,  most  of  the  differences  between  my  IL  and  the  Harper-Stone  IL  corre¬ 
spond  to  the  differences  between  my  system  and  HL’s  (see  Section  2.2.1).  For  instance,  HL  model 
translucency  through  an  explicit  distinction  between  opaque  and  transparent  type  specifications 
in  signatures,  whereas  I  support  translucency  at  the  core-language  level  via  singleton  kinds.  HL 
support  only  generative  functors  and  impure  sealing,  whereas  I  support  two  forms  of  functors  and 
two  forms  of  sealing. 

There  are  a  variety  of  other  small  differences,  including: 

•  The  HS  IL  supports  polymorphism  only  indirectly,  through  the  module  system,  as  a  way  of 
emphasizing  the  second-class  character  of  polymorphism  in  ML.  That  is,  to  write  a  polymor¬ 
phic  function,  one  must  write  a  functor  that  takes  as  input  a  module  with  one  type  component 
and  returns  as  output  a  module  with  one  monomorphic  function  component.  My  IL  supports 
polymorphism  directly  in  the  core  language  in  the  style  of  System  F^. 

•  The  HS  IL  distinguishes  between  total  and  partial  functions  and  functors,  but  what  HS 
mean  by  “total”  and  “partial”  is  different  from  what  those  terms  mean  in  my  IL.  A  total 
function/functor  in  HS  is  one  whose  body  is  valuable,  i.e.,  effect-free  and  terminating.  The 
bodies  of  total  functors  in  my  IL  may  have  arbitrary  effects  as  long  as  they  are  separable. 

HS  track  totality  for  two  reasons.  First,  datatype  constructors  need  to  be  given  total  ar¬ 
row  types  so  that  one  may  observe  that  datatype  constructor  applications  are  valuable  and 
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thus  eligible  for  polymorphic  generalization.  I  address  this  issue  in  my  language  by  giving 
datatype  constructors  coercion  types,  and  by  observing  that  coercion  applications  are  always 
valuable.  Second,  HS  model  polymorphic  functions  as  total  functors  in  order  to  observe  that 
the  instantiation  of  a  type  abstraction  is  a  valuable  operation.  In  my  language,  I  require  the 
body  of  a  type  abstraction  to  be  valuable,  and  therefore  consider  type  instantiation  to  always 
be  a  valuable  operation. 

•  HS  characterize  valuable  expressions  by  means  of  a  valuability  judgment  (F  h  exp  J,  con), 
whereas  I  simply  characterize  them  as  a  syntactic  subclass,  which  I  write  vexp.  The  only 
reason  I  can  do  this  and  HS  cannot  is  that  HS  do  not  make  a  syntactic  distinction  between 
total  and  partial  function  application. 

•  The  HS  dynamic  semantics  employs  a  standard  call-by-value  left-to-right  evaluation  scheme. 
In  contrast,  my  IL  requires  all  sequencing  of  term-level  operations  to  be  made  explicit  through 
the  use  of  a  let  expression.  Thus,  for  instance,  function  application  requires  both  the  function 
and  its  argument  to  be  values.  As  I  illustrated  in  Sections  3.2  and  6.2,  it  is  completely 
straightforward  to  use  let  expressions  to  define  less  restrictive  versions  of  most  constructs, 
wherein  subterms  are  not  required  to  be  values  and  are  evaluated  left  to  right. 

•  For  the  purpose  of  defining  its  dynamic  semantics,  the  HS  IL  introduces  explicit  syntactic 
classes  of  memory  locations  (loc)  and  extensible  sum  tags  (tag),  whereas  I  model  these  no¬ 
tions  directly  in  terms  of  variables.  On  the  other  hand,  HS  join  constructor  variables,  term 
variables  and  module  variables  under  one  syntactic  class  (var).  For  clarity,  I  make  a  syntactic 
distinction  between  cvaYs,  evaYs  and  mvaYs,  although  I  sometimes  use  var  to  signify  any 
kind  of  variable. 

•  Lastly,  my  IL  fixes  a  number  of  bugs  and  omissions  in  the  HS  IL. 


8.2  IL  Syntax 

Figures  8. 1-8.8  present  the  syntax  of  my  internal  language.  I  assume  the  following  notational 
conventions; 

•  For  any  syntactic  class  {e.g.,  labeled  bindings,  represented  by  the  metavariable  Ibnd),  I  use 
the  plural  of  the  metavariable  {e.g.,  Ibnds)  to  denote  a  sequence  of  zero  or  more  elements  of 
the  original  class,  separated  by  commas. 

•  Names  for  metavariables  are  complicated  but  logical.  I  use  the  letter  p  to  mean  projectible,  the 
letter  t  to  mean  transparent,  the  letter  c  to  mean  constructor,  the  letter  v  to  mean  valuable, 
and  the  letter  I  to  mean  labeled.  For  instance,  tlcdec  denotes  a  transparent,  labeled  constructor 
declaration  (see  Figure  8.5).  For  those  familiar  with  Harper-Stone,  the  metavariables  Ibnds 
and  Idecs  replace  HS’s  sbnds  and  sdecs. 

•  Sequences  of  syntactic  objects  are  assumed  to  be  ordered,  unless  they  appear  inside  curly 
braces,  in  which  case  they  are  identified  up  to  reordering.  The  only  instances  of  unordered 
sequences  are  in  the  syntax  of  record  and  sum  types. 

•  I  sometimes  write  {phrase where  phrase^  is  some  syntactic  phrase  that  depends  on  i,  to 
denote  the  sequence  phrase i,  ■  ■  ■ ,  phrase n. 
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•  I  assume  as  a  precondition  for  syntactic  well-formedness  that,  in  any  sequence  of  bind¬ 
ings/declarations  {e.g.,  labi>vari:sigi,  ■  ■  ■ ,  labn>varn'sigj^),  all  the  labels  labi,  ■  ■  ■ ,  labn  are 
distinct,  and  all  the  variables  vari,  •  •  • ,  vavn  are  distinct.  Furthermore,  I  treat  each  vavi  as 
being  bound  in  the  bindings/declarations  that  come  after  it.  Sometimes  I  omit  the  variables 
and  simply  write  labi'.sigi,  •  •  • ,  labn'-sig^,  when  I  have  no  need  to  refer  to  the  variable  names. 

•  As  in  the  simplified  IL,  I  write  phrase' [phrase / var]  to  denote  the  capture-avoiding  substi¬ 
tution  of  phrase  for  var  in  phrase' .  When  the  phrase  being  substituted  is  a  pmod  {i.e.,  a 
projectible  module),  phrase' [pmod / mvar]  is  shorthand  for  phrase' [fst{pmod)/mvar'^],  where 
mvar'^  is  the  injection  of  mvar  into  the  class  of  constructor  variables.  I  will  sometimes  write 
phrase' [phrase i/ var as  shorthand  for  phrase' [phrase i/vari]  ■  ■  ■  [phrase var „\- 

•  As  in  the  simplihed  IL,  I  write  p{sig)  as  shorthand  for  p{mvar).sig  when  mvar^  0  FV(si5). 
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knd 

:= 

T 

1 

5(con) 

1 

{Icdecs} 

1 

Il{cvar:knd).knd' 

boon 

;  = 

Int  Float  •  •  • 

1 

{rdecs} 

1 

con  Ref 

1 

con  con' 

1 

con  ^  con' 

1 

Tagged 

1 

con  Tag 

1 

S{  rdecs} 

1 

\/{cvar:knd).con 

1 

3{cvar:knd) .  con 

1 

maybe(con) 

con 

:= 

bcon 

1 

cvar 

1 

li{cvar:knd).con 

1 

X{  cvar:  knd).  con 

1 

con{con') 

i 

[Icbnds] 

1 

con.  lab 

rdec 

:= 

lab:  con 

Icbnd 

1  — 

lab>cbnd 

cbnd 

:= 

cvar = con 

Icdec 

1  — 

lab\>cdec 

cdec 

cvar:knd 

kind  of  types 
singleton  kind 
record  kind 
arrow  kind 

base  types 
record  type 
reference  type 
function  type 
coercion  type 
extensible  sum  type 
exception-tag  type 
sum  type 
universal  type 
existential  type 
recursive  variable  type 

constructors  of  base  kind  T 
constructor  variable 
iso-recursive  constructor 
constructor-level  function 
constructor  application 
record  of  constructors 
record  projection 

record  field  type 

labeled  constructor  binding 
constructor  binding 

labeled  constructor  declaration 
constructor  declaration 


elim  ::= 

• 

elimination  head 

1 

elim. lab 

projection 

elim{con) 

application 

cpath  ::  = 

bcon 

base  type 

1 

elim{cvar} 

path  rooted  at  variable 

1 

recpath 

recursive  type  path 

recpath  ::= 

elim{fi{cvar:knd)  .con} 

path  rooted  at  ;U-constructor 

Figure  8.1;  IL  Constructors  and  Kinds 
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val 

:= 

scon 

constant 

1 

evar 

expression  variable 

1 

{rbnds} 

record  value 

1 

f'lxi^fbnds  end 

recursive  function 

1 

sum  injection 

1 

tag(?;a/,  val') 

extensible  type  injection 

1 

fold  con 

fold  coercion 

1 

unfold™” 

unfold  coercion 

1 

fold™”((?;a/)) 

coercion  application 

1 

A{cvar:knd).vexp 

type  abstraction 

1 

pack  [con,  val]  as  con' 

existential  introduction 

exp 

;  = 

val 

value 

1 

'^lab 

record  projection 

1 

val  val' 

application 

1 

handle  exp  with  val 

handle  exception 

1 

raise™”  val 

raise  exception 

1 

ref  val 

allocate  new  ref  cell 

1 

get  val 

dereference  a  ref  cell 

1 

set  (val,  val') 

update  a  ref  cell 

1 

val  {{val')) 

coercion  application 

1 

val[con] 

type  instantiation 

1 

case  val  of  {labi^vali)'^^^  end 

sum  case  analysis 

1 

new_tag[con] 

extend  type  Tagged 

1 

iftagof  val  is  val'  then  val"  else 

exp 

exception  tag  case  analysis 

1 

let  [cvar,  evar]  =  unpack  val  in 

{exp  :  con) 

existential  elimination 

1 

let  cvar=con  in  exp 

cvar-binding  let  expression 

1 

let  evar=exp'  in  exp 

e?;ar-binding  let  expression 

1 

let  mvar=niod  in  {exp  :  con) 

TOuar-binding  let  expression 

1 

rec{evar:con.exp) 

recursive  expression 

1 

Ietch{val) 

dereference  a  recursive  variable 

1 

mod. lab 

module  projection 

1 

pack  mod  as  sig 

first-class  module  packing 

rbnd 

:= 

II 

record  field  binding 

fbnd 

:= 

evar'  {evar:con):con'=exp 

(recursive)  function  binding 

Figure  8.2;  IL  Values  and  Expressions 
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mod  :: 


Ibnd  :: 
bnd  :: 


sig  :: 


Idee  :: 
dec  :: 


var  :: 


mvar 

module  variable 

[Ibnds] 

structure 

mod. lab 

projection  from  structure 

( mvar :  sig).  mod 

total  functor 

{mvar:sig)-.sig'  .mod 

partial  functor 

mod^°^  {mod') 

total  functor  application 

mod^^'  (mod') 

partial  functor  application 

mod  :  >p  sig 

basic  (weak)  sealing 

mod  :  >i  sig 

impure  (strong)  sealing 

unpack  exp  as  sig 

first-class  module  unpacking 

purify(mod) 

purification  of  transparent  module 

let  mvar=mod  in  {mod' :  sig) 

let  module 

roll  (mod) 

rds  introduction 

unroll(mod) 

rds  elimination 

fetch  (mod) 

dereference  a  recursive  module  variable 

rec  ( mvar :  tsig  .mod) 

recursive  module 

lab>bnd 

labeled  binding 

cvar=con 

constructor  binding 

evar=exp 

expression  binding 

mvar=mod 

module  binding 

|Wecs] 

structure  signature 

{mvar -.sig).  sig' 

total  functor  signature 

{mvar:  sig).  sig' 

partial  functor  signature 

p{mvar).sig 

recursively  dependent  signature  (rds) 

maybe{sig) 

memoized  computation  signature 

lab>dec 

labeled  declaration 

cvar:knd 

constructor  declaration 

evar:con 

expression  declaration 

mvar:  sig 

module  declaration 

evar 

constructor  variable 

evar 

expression  variable 

mvar 

module  variable 

Figure  8.3;  IL  Modules  and  Signatures 
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vexp  ::=  val 

I  T^iab  vexp 
I  vexp  {{vexp')) 

I  vexp[con] 

I  '^'£bvexp 

I  tag{vexp,  vexp') 
I  vmod.lab 


vmod  ::= 


vlbnd  :;= 
vbnd  ::= 


mvar 

[vlbnds] 

vmod.lab 

{mvav.sig)  .mod 
{mvar-.sig)-.sig'  .mod 
'co\\{vmod) 
ur\ro\\{vmod,) 

lab>vbnd 

cvar=vexp 

evar=con 

mvar=vmod 


Figure  8.4;  IL  Valuable  Expressions 


pmod  ::=  mvar 

I  [plbnds] 

I  pmod.  lab 
I  {mvar  :sig). pmod 

I  X^^'  {mvar:sig):sig'  .mod 
I  pmod^°^{pmod') 

I  roll  (pmod) 

I  unroll  (pmod) 

I  rec{mvar:tsig.mod) 

I  fetch  (pmod) 

plbnd  ::=  lab>pbnd 
pbnd  ::=  cvar=con 
I  evar=exp 
I  mvar=pmod 


tknd  ::=  5{con) 

I  |tZcdecs] 

I  Il{cvar:knd).tknd' 

tlcdee  ;:=  lab\>tcdec 
tcdec  ::=  cvar:tknd 

tsig  ::=  |tWecs] 

I  lT°^{mvar:sig).tsig' 
I  nP^'’(muar:sig').si5' 

I  p{mvar).tsig 
I  maybe(tsi5) 

tWec  ::=  lab>tdec 
tdec  ::=  cvar:tknd 
I  evar:con 
I  mvar -.tsig 


Figure  8.5:  IL  Projectible  Modules  and  Transparent  Kinds/Signatures 


8.2.  IL  SYNTAX 


175 


sfknd  ::=  T 

I  \lahi\sfkndi,-  ■  ■  ,lahn'.sfknd^ 

I  sfknd^  sfknd' 


eknd  ::=  tknd 

I  T 

I  {labi'.ekndi,  ■  ■  ■ ,  labn'.ekndnl 
I  Il{cvar:  sfknd).  eknd 


h  recpath  |  ,  lab:knd,  •  •  •]  h  recpath  |  Il{cvar:knd') .knd 

h  ^{cvar:knd).con  ]  knd  h  recpath. lab  ]  knd  h  reepath{con)  t  knd 

h  reepath  |  T  reepath  =  elim{fj,{evar: eknd). eon} 
h  reepath  expands 


expand(e/im{^(ct'ar:/cnd).con})  =  e/im{con[/i(ct'ar:/cnd).con/cuar]} 


Figure  8.6;  IL  Expandable  Kinds  and  Recursive  Type  Paths 


h  [-1  =1  [CTar:|-].{-}| 
h  I  Wees]  ^  |e?;ar:[W(iecs|.{rdecs}| 


h  llab>cvar':knd,  Idecs}  ^  lcvar:llab>cvar':knd,lcdecs}.{rdees}[evar.lab/cvar']l 

h  I  Wees]  ^  |et'ar;[/cdecs|.{rdecs}| 
h  |W6i>emr: eon,  Wees]  |cuar:|/c(iecs|.{W6:con,  rdecs}] 

h  sig  ^  Imvar^-.knd.con}  h  |Wecs|  ^  |et'ar:[/cdecs|.{rdecs}] 


h  |Za6i>mmr:si5,  Wees]  levar:llab>mvar^:knd,  ledecs}.{lab:eon,  rdecs}[cvar.lab /mvar^]} 

h  sig  ^  fend. con]  h  sig'  =1  |cmr':A:nd'.con'| 

h  W-°^{mvar:sig).sig'  ^  lcvar:Il{mvar'^:knd).knd' .y{mvar‘^:knd).con  -i-  con'[evar{mvar‘^)/ evar']} 

h  sig  ^  fend. con]  h  sig'  =1  {cvar'-.knd' .con'j 

l_  nP^''(mmr:sig).sig'  |er;ar:|-].V(mmr‘^:A;nd).eon  ^  3(er;ar':fcnd').con'] 

h  sig  |e?;ar:fcnd.con| 
h  p{mvar).sig  ^  |c?;ar:/cnd.con[cmr/m?;ar'^]] 

h  sig  =1  \evar-.knd .con\ 
h  maybe(sig)  =1  |et'ar;A:nd.maybe(eon)] 

(|sigD  '=  3{cvar:knd).eon,  where  h  sig  ^  |c?;ar:A:nd.con| 

Figure  8.7;  IL  Definition  of  Package  Type 
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Can{tknd) 

Can(S(con)) 

Car\{\tlcdecs\) 
Can{Il{cvar-.knd)  .tknd') 

=  con 

=  [Can  {tlcdecs)] 

=  X{cvar:knd)  .Can{tknd') 

Can{tlcdecs) 

Can(-) 

Can{lab>cvar:tknd,  tlcdecs) 

=  lab>cvar=Can{tknd) ,  Can{tlcdecs) 

Fst(sifi-) 

Fst(|/decs]) 

Fst  ( m?;ar :  sigf) . 

{mvar:sig).sig') 

fst{p{mvar).sig) 

Fst(maybe(sig)) 

=  |Fst(Wecs)] 

=  n(muar‘^:Fst(sig')).Fst(si(/') 

=  H 

=  Fst(sig),  where  mvar’^  ^  FV(Fst(si5')) 

=  Fst  (sig) 

Fst(Wecs) 

Fst(-) 

fst{lab>cvar:knd,  Ideas) 
fst{lab\>evar:con,  Idecs) 
fst{lab>mvar:sig,  Ideas) 

=  lab\>cvar:knd,  Fst(Wecs) 

=  Fst(/decs) 

=  lab\>mvar'^Pst{sig),Vst{ldecs) 

Vst[pmod) 

fst{mvar) 

fst{[plbnds]) 

fst{pmod.lab) 

Fst  ( ( mvar  :sig).pmod) 
fst{X^^''  {mvar:sig):sig'  .mod) 
Fst{pmod^°^  {pmod')) 
fst{ro\\  (pmod)) 
Fst(unroll(pmo(i)) 
Fst(fetch(pmo(i)) 

Fst  ( rec  ( mvar :  tsig  .mod)) 

=  mvar’^ 

=  [fst{plbnds)] 

=  fst{pmod).lab 
=  X{mvar’^:fst{sig)).fst{pmod) 

=  [■] 

=  fst{pmod){fst{pmod')) 

=  fst{pmod) 

=  F5t{pmod) 

=  Fst(pmod) 

=  Can(Fst(tsig)) 

Vst{plhnds) 

Fst(-) 

fst{lab>cvar=con,  plbnds) 
fst{lab>mvar=pmod,  plbnds) 
fst{lab>evar=exp,  plbnds) 

=  lab>cvar=con,  fst{plbnds) 

=  lab>mvar’^=fst{pmod),  fst{plbnds) 

=  fst{plbnds) 

5{con  :  knd) 

5{con  :  T) 

S(con :  S(con')) 

5{con  :  pcdecs]) 

5{con :  Il{cvar:knd) .knd') 

=  S(con) 

=  5  {con) 

=  {5 {con  :  Icdecs)} 

=  Il{cvar:knd) .5{con{cvar) :  knd') 

5{con  :  sig) 

5 {con :  |Wecs]) 

5(con  :  {mvar:sig) .sig') 

5{con  :  {mvar:sig) .sig') 

5{con :  p{mvar).sig) 

5{con :  maybe{sig)) 

=  \5{con :  ldecs)\ 

=  lT°^{mvar:sig) .Q{con{mvar'^) :  sig') 

=  {mvar :  sig)  .sig' 

=  p{5{con:  sig[con/mvar'^\)) 

=  maybe(S(con ;  sig)) 

5 {con  :  Idecs) 

5{con  :  •) 

S(con:  lab>cvar: knd,  Idecs) 

5{con:  lab>evar:con,  Ideas) 
5{con:  lab>mvar: sig,  Ideas) 

=  lab :5 {con. lab  :  knd), 

5{con  :  ldecs[con.lab / cvar]) 

=  lab: con, 5 {con  :  Idecs) 

=  lab:5{con.lab  :  sig), 

5{con  :  ldecs[con.lab / mvar"^]) 

Figure  8.8;  IL  Meta-level  Function  Definitions 


8.3.  IL  STATIC  SEMANTICS 


177 


8.3  IL  Static  Semantics 

As  in  the  simplified  IL,  wherever  “static”  judgments  77  (i.e.,  judgments  about  kinds,  constructors  or 
signatures,  wherein  the  context  is  a  sequence  of  cdecs  instead  of  decs)  are  invoked  with  “dynamic” 
contexts  decs,  this  is  shorthand  for  the  conjunction  of  h  decs  ok  and  Fst(decs)  h  J . 

Well-formed  Declarations 

I  h  decs  ok  I 

h  •  ok 

decs  h  dec  ok 
h  decs,  dec  ok 


(8.1) 

(8.2) 


decs  h  knd  :  Kind  cvar  0  dom(decs) 
decs  h  cvar-.knd  ok 

decs  h  con  :  T  evar  0  dom( decs) 
decs  h  evar:  con  ok 

decs  h  sig  :  Sig  mvar  0  dom(decs) 
decs  h  mvar: sig  ok 


decs  h  dec  ok 


(8.3) 

(8.4) 

(8.5) 


Well-formed  Bindings 


decs  h  con  :  knd 
decs  h  cvar=con  cvar:knd 

decs  h  exp  :  con 
decs  h  evar=exp  :p  evar:con 

decs  h  mod  :k  sig 
decs  h  mvar = mod  mvar: sig 


decs  h  bnd  dec 


(8.6) 

(8.7) 

(8.8) 


Well-formed  Kinds 


cdecs  h  knd  :  Kind 

h  cdecs  ok 

(8.9) 

cdecs  h  T  :  Kind 

cdecs  h  con  :  T 

(8.10) 

cdecs  l-S(con)  :  Kind 

cdecs  h  Icdecs  ok 

(8.11) 

cdecs  h  [/cdecs]  :  Kind 

cdecs,  cvar-.knd  h  knd'  :  Kind 
cdecs  h  Il{cvar:knd) .knd'  :  Kind 

(8.12) 
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Kind  Equivalence 


h  cdecs  ok 
cdecs  h  •  =  • 


cdecs  h  Icdecs  =  Icdecs' 


(8.13) 


cdecs  h  knd  =  knd'  cdecs,  cvar-.knd  h  Icdecs  =  Icdecs' 
cdecs  h  lab> cvar-.knd,  Icdecs  =  lab\>cvar:knd' ,  Icdecs' 


(8.14) 


cdecs  h  knd  =  knd' 


h  cdecs  ok 

(8.15) 

edees  h  T  =  T 

cdecs  h  con  =  con'  :  T 

(8.16) 

cdecs  h  S(con)  =  5{con') 

cdecs  h  Icdecs  =  Icdecs' 

(8.17) 

cdecs  h  [/cdecs]  =  [/cdecs'] 

cdecs  h  kndi  =  knd'i  cdecs,  cvar:kndi  h  knd2  =  knd'2 

(8.18) 

cdecs  h  H{cvar:kndi).knd2  =  Il{cvar:knd'i).knd'2 

Kind  Subtyping 


h  cdecs  ok 
cdecs  h  •  <  • 


cdecs  h  Icdecs  <  Icdecs' 


(8.19) 


cdecs  h  knd  <  knd'  cdecs,  cvar-.knd  h  Icdecs  <  Icdecs' 
cdecs  h  lab> cvar-.knd,  Icdecs  <  lab>cvar:knd' ,  Icdecs' 


(8.20) 


cdecs  h  knd  <  knd' 

h  cdecs  ok 

(8.21) 

cdecs  h  T  <  T 

cdecs  h  con  =  con'  :  T 

(8.22) 

cdecs  h  S(con)  <  5{con') 

cdecs  h  con  :  T 

(8.23) 

cdecs  h  5(con)  <  T 

cdecs  h  Icdecs  <  Icdecs' 
cdecs  h  [/cdecs]  <  [/cdecs'] 

(8.24) 

cdecs  h  Il{cvar-.kndi) .knd2  '■  Kind 

cdecs  h  knd'i  <  kndi  cdecs,  cvar-.knd'^  h  knd2  <  knd'2 
cdecs  h  Il{cvar:kndi) .knd2  <  Il{cvar:knd'i). knd'2 


(8.25) 
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Well-formed  Constructors 


cdecs  h  con  :  knd 

h  cdecs  ok  cvav.knd  €  cdecs 

(8.26) 

cdecs  h  cvar  :  knd 

h  cdecs  ok 
cdecs  h  Tagged  :  T 

(8.27) 

cdecs  h  con  :  T 

(8.28) 

cdecs  h  con  Ref  :  T 

cdecs  h  con  :  T 

(8.29) 

cdecs  h  con  Tag  :  T 

cdecs  h  con  :  T  cdecs  h  con'  :  T 

(8.30) 

cdecs  h  con  con'  :  T 

cdecs  h  con  :  T  cdecs  h  con'  :  T 

(8.31) 

cdecs  h  con  -w  con'  :  T 

cdecs  h  con  :  T 

(8.32) 

cdecs  h  maybe(con)  :  T 

h  cdecs  ok  Vi  €  l..n  :  cdecs  h  coni  :  T 

(8.33) 

cdecs  h  {ia6i;coni, . . . ,  labn'.conn}  ■  T 

h  cdecs  ok  Vi  G  l..n  :  cdecs  h  coni  :  T 

(8.34) 

cdecs  h  E{lahi:coni, . . . ,  labn'.conn}  '■  T 

cdecs,  cvar: knd  h  con  :  T 
cdecs  h  \/ {cvav.knd). con  :  T 

(8.35) 

cdecs,  cvar:knd  h  con  :  T 
cdecs  h  3{cvar:knd) . con  :  T 

(8.36) 

cdecs,  cvar:knd  h  con  :  knd 
cdecs  h  iJ,{cvar:knd).con  :  knd 

(8.37) 

cdecs  h  Icbnds  :  Icdecs 

(8.38) 

cdecs  h  [Icbnds]  :  |/c(iecs] 

cdecs  h  con  :  ,  labi>cvari:kndi,  ■  ■  •] 

cdecs  h  con.labi  :  kndi[con.labj/cvarjYj^^ 

(8.39) 

cdecs,  cvar:knd  h  con  :  knd' 

(8.40) 

cdecs  h  \{cvar:knd) .con  :  Il{cvar:knd) .knd' 

cdecs  h  con  :  Il{cvar:knd').knd  cdecs  h  con'  :  knd' 

(8.41) 

cdecs  h  con{con')  :  knd[con' / cvar] 

cdecs  h  con  :  T 
cdecs  h  con  :  5 (con) 

(8.42) 
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cdecs  h  con  :  l{labi>cvari:knd'j}'^^-^J  Vi  G  l..n  :  cdecs  h  con.labi  :  kndi 
cdecs  h  con  :  \{lahi\kndi)'2^^ 

cdecs  h  con  :  Il{cvar:knd) .knd'  cdecs,  cvar:knd  h  con{cvar)  :  knd" 

cdecs  h  con  :  Il{cvar\knd).knd" 

cdecs  h  con  ;  knd'  cdecs  h  knd'  <  knd 
cdecs  h  con  :  knd 


(8.43) 

(8.44) 

(8.45) 


Constructor  Equivalence 


h  cdecs  ok 
cdecs  [-•  =  •:• 


cdecs  h  Icbnds  =  Icbnds'  :  Icdecs 


(8.46) 


cdecs  h  con  =  con'  :  knd  cdecs,  cvar:knd  h  Icbnds  =  Icbnds'  :  Icdecs 
cdecs  h  lab\>cvar=con,  Icbnds  =  lab\>cvar=con' ,  Icbnds'  :  lab\>cvar:knd,  Icdecs 


(8.47) 


cdecs  h  con  :  knd 
cdecs  h  con  =  con  :  knd 

cdecs  h  con'  =  con  :  knd 
cdecs  h  con  =  con'  :  knd 


cdecs  h  con  =  con'  :  knd 

(8.48) 

(8.49) 


cdecs  h  con  =  con'  :  knd 
cdecs  h  con'  =  con"  :  knd 
cdecs  h  con  =  con"  ;  A:nd 


(8.50) 


cdecs  h  coni  ^  S(con)  cdecs  h  con2  :  S(con) 
cdecs  h  coni  =  con2  :  S(con) 

cdecs  h  coni  =  con2  '■  T  cdecs  h  con'^  =  con^  :  T 
cdecs  h  coni  ^  con'^  =  con2  ^  con^  :  T 

cdecs  h  coni  =  con2  ■  T  cdecs  h  con'^  =  con'2  '■  T 
cdecs  h  coni  con'^  =  con2  con'2  • 

cdecs  h  con  =  con'  :  T 
cdecs  h  con  Ref  =  con'  Ref  :  T 


cdecs  h  con  =  con'  :  T 
cdecs  h  con  Tag  =  con'  Tag  :  T 

h  cdecs  ok  Vi  G  l..n  :  cdecs  h  con*  =  con'  :  T 
cdecs  h  {ia6i:coni,  •  •  • ,  labn-conn}  =  {ia6i;con'^,  •  •  • ,  labn'-con'^}  :  T 

h  cdecs  ok  Vi  G  l..n  :  cdecs  h  con*  =  con'  :  T 
cdecs  h  S{ia6i:coni, . . . ,  labn'conn}  =  S{/o6i;con'^, . . . ,  labn-con'^}  '■  T 


(8.51) 

(8.52) 

(8.53) 

(8.54) 

(8.55) 

(8.56) 


(8.57) 
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cdecs  h  knd  =  knd'  cdecs,  cvar:knd  h  con  =  con'  :  T 
cdecs  h  V{cvar:knd).con  =  y{cvar:knd').con'  :  T 

cdecs  h  knd  =  knd'  cdecs,  cvar:knd  h  con  =  con'  :  T 
cdecs  h  3{cvar:knd) . con  =  3{cvar:knd') .con'  :  T 

cdecs  h  con  =  con'  :  T 
cdecs  h  maybe(con)  =  maybe(con')  :  T 

cdecs  h  knd  =  knd'  cdecs,  cvar:knd  h  con  =  con'  :  knd 
cdecs  h  ii{cvar:knd) .con  =  fi{cvar:knd') .con'  :  knd 

cdecs  h  Icbnds  =  Icbnds'  :  Icdecs 
cdecs  h  [Icbnds]  =  [Icbnds']  :  pcrfecs] 

cdecs  h  con  =  con'  ;  ,  labi^cvarf.kndi,  ■  ■  •] 

cdecs  h  con.labi  =  con'.labi  :  kndi[con.labj/cvarj\'~}^ 

cdecs  h  knd  =  knd'  cdecs,  cvar-.knd  h  con  =  con'  ;  knd" 
cdecs  h  X{cvar:knd).con  =  \{cvar:knd') .con'  ;  Il{cvar:knd).knd'' 

cdecs  h  coni  =  con2  :  n(ccar:/cnd').A:nrf  cdecs  h  con'^  =  con^  :  A;nd' 
cdecs  h  coni(con'^)  =  con2{con'2)  :  A:nd[con'^/ccar] 

cdecs  h  con'  :  \{lahi\>cvari-.knd'j)'^^.^  cdecs  h  con"  ;  \{labi\>cvari-.knd'l)'^^.^ 
Vi  G  l..n  :  cdecs  h  con' .labi  =  con" .lab i  :  kndi 
cdecs  h  con'  =  con"  : 

cdecs  h  coni  :  Il{cvar-.knd).kndi  cdecs  h  con2  :  n(ccar:icnd).A:nd2 
cdecs,  cvar-.knd  h  coni{cvar)  =  con2{cvar)  :  knd' 
cdecs  h  coni  =  con2  :  Il{cvar-.knd) .knd' 

cdecs  h  coni  =  con2  :  knd'  cdecs  h  knd'  <  knd 
cdecs  h  coni  =  con2  :  knd 


(8.58) 

(8.59) 

(8.60) 
(8.61) 
(8.62) 

(8.63) 

(8.64) 

(8.65) 

(8.66) 

(8.67) 

(8.68) 


Well-formed  Expressions 


h  decs  ok 

decs  h  scon  :  type(scon) 

h  decs  ok  evar:con  €  decs 
decs  h  ecar  ;  con 

decs  h  val  :  con'  ^  con  decs  h  val'  :  con' 
decs  h  cai  val'  :  con 


decs  h  exp  :  con 


(8.69) 

(8.70) 

(8.71) 


Vi  G  l..n  ;  decs,  {evar'.-.conj  —>■  con'j)'^^^,  evarpconi  h  exp^  :  con'^ 
decs  h  fixfc  (ecar'(ecari;conj):con'=expj)”^j^  end  :  con^  — >  con'^ 


(8.72) 
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h  decs  ok  Vi  G  l..n  :  decs  h  vali  :  corii 
decs  h  {labi=vali,  ■  ■  ■ ,  labn=valn}  '■  {labi'.coni,  •  •  • ,  labn'conn} 

decs  h  val  :  {rdecs,  lab: con,  rdecs'} 
decs  h  TTiab  val  :  con 

decs  h  exp  :  con  decs  h  val  :  Tagged  ^  con 
decs  h  handle  exp  with  val  :  con 

decs  h  val  :  Tagged  decs  h  con  :  T 
decs  h  raise™"  val  :  con 

decs  h  con  :  T 

decs  h  new_tag[con]  :  con  Tag 

decs  h  val  :  con 
decs  h  ref  val  :  con  Ref 

decs  h  val  :  con  Ref 
decs  h  get  val  :  con 

decs  h  val  :  con  Ref 
decs  h  val'  :  con 
decs  h  set  {val,  val')  :  {} 

decs  h  con  =  recpath  :  T  h  recpath  expands 
decs  h  fold™"  :  expand(recpai/i)  recpath 

decs  h  con  =  recpath  :  T  h  recpath  expands 
decs  h  unfold™"  ;  recpath expand{recpath) 

decs  h  val  :  con'  con  decs  h  val'  :  con' 
decs  h  val{{val'))  :  con 

decs,  cvav.knd  h  vexp  :  con 
decs  h  A{cvar:knd) .vexp  :  \/{cvar:knd).con 

decs  h  val  :  \/{cvar:knd).con'  decs  h  con  :  knd 
decs  h  val[con]  :  con'[con/ cvar] 

decs  h  con'  =  3{cvar:knd) .con"  :  T 
decs  h  con  :  knd  decs  h  val  :  con" [con/ cvar] 
decs  h  pack  [con,  val]  as  con'  :  con' 

decs  h  val  :  3{cvar:knd) .con' 
decs,  cvav.knd,  evav.con'  h  exp  :  con  decs  h  con  :  T 
decs  h  let  [cvar,  evar]  =  unpack  val  in  {exp  :  con)  :  con 

decs  h  con  =  E^lab'.con' ,  •  •  •}  :  T  decs  h  val  :  con' 
decs  h  inj;™^  val  :  con 


(8.73) 

(8.74) 

(8.75) 

(8.76) 

(8.77) 

(8.78) 

(8.79) 

(8.80) 
(8.81) 
(8.82) 

(8.83) 

(8.84) 

(8.85) 

(8.86) 

(8.87) 

(8.88) 
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decs  h  val  :  T,{labi:coni, . . . ,  labn-coun}  Vi  €  l..n  :  decs  h  vah  :  corii  con 
decs  h  case  val  of  {labie^vali)'^^^  end  :  con 


(8.89) 


decs  h  val  :  con  Tag  decs  h  val'  :  con 
decs  h  tag(?;a/,  val')  :  Tagged 

decs  h  val  :  Tagged  decs  h  val'  :  con  Tag 
decs  h  val"  :  con  — >  con'  decs  h  exp  :  con' 

decs  h  iftagof  val  is  val'  then  val"  else  exp  :  con' 

decs  h  con  :  knd  decs,  cvav.knd  h  exp  :  con' 
decs  h  let  cvar=con  in  exp  :  con'[con / cvar] 

decs  h  exp  :  con  decs,  evav.con  h  exp'  :  con' 
decs  h  let  evar=exp  in  exp'  :  con' 


(8.90) 


(8.91) 


(8.92) 


(8.93) 


decs  h  mod  sig  decs,  mvav.sig  h  exp  :  con  decs  h  con  :  T 
decs  h  let  mvar=mod  in  {exp  :  con)  :  con 

decs,  evar:maybe{con)  h  exp  :  con 
decs  h  rec{evar:con.exp)  :  con 


(8.94) 


(8.95) 


decs  h  val  :  maybe(con) 
decs  h  fetch (ca/)  :  con 

decs  h  pmod  ;p  ,  labi^varp.coni,  ■  ■  •] 
decs  h  pmod.labi  :  coni[pmod .lab j / var 

decs  h  mod  sig 
decs  h  pack  mod  as  sig  :  (|sigD 

decs  h  exp  :  con'  decs  h  con'  =  con  :  T 
decs  h  exp  :  con 


(8.96) 


(8.97) 


(8.98) 


(8.99) 


Well-formed  Signatures 


h  cdecs  ok 
cdecs  h  •  ok 


cdecs  h  Idecs  ok 


(8.100) 


cdecs,  dec  h  Idecs  ok 
cdecs  h  labt>dec,  Idecs  ok 


(8.101) 
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cdecs  h  sig  :  Sig 

cdecs  h  Idecs  ok 
cdecs  h  [/decs]  :  Sig 

(8.102) 

cdecs  h  sig  :  Sig  cdecs,  mvaH:fst{sig)  h  sig'  :  Sig 

cdecs  h  n'^°'^(mcar:si5').si5'  :  Sig 

(8.103) 

cdecs  h  sig  :  Sig  cdecs,  mvaH‘Pst{sig)  h  sig'  :  Sig 

cdecs  h  nP^''(mcar:si5').si5'  :  Sig 

(8.104) 

cdecs,  mvaNPst{sig)  h  si^  :  Sig 
cdecs  h  p{mvar).sig  :  Sig 

(8.105) 

cdecs  h  si^  :  Sig 
cdecs  h  maybe(sz5)  :  Sig 

(8.106) 

Signature  Equivalence 


h  cdecs  ok 
cdecs  h  •  =  • 


cdecs  h  Idecs  =  Idecs' 


(8.107) 


cdecs  h  knd  =  knd'  cdecs,  cvar:knd  h  Idecs  =  Idecs' 
cdecs  h  lab>cvar:knd,  Idecs  =  lab>cvar:knd' ,  Idecs' 

cdecs  h  con  =  con'  :  T  cdecs  h  Idecs  =  Idecs' 
cdecs  \-  lab>evar:con,  Idecs  =  lab\> evar: con' ,  Idecs' 

cdecs  h  sig  =  sig'  cdecs,  nivaHPst{sig)  h  Idecs  =  /decs' 
cdecs  h  lab>mvar:sig,  Idecs  =  lab>mvar:sig' ,  Idecs' 


(8.108) 

(8.109) 

(8.110) 


cdecs  h  Idecs  =  /decs' 
cdecs  h  |/decs]  =  [/decs'] 


cdecs  h  sig  =  sig' 


(8.111) 


cdecs  h  si^i  =  sig2  cdecs,  mvaNPst{sig i)  h  sig'^  =  sig'2 
cdecs  h  n'^°'^(mcar:si5'i).si5'^  =  IT°^{mvar\sig2)-sig'2 


(8.112) 


cdecs  h  si^i  =  sig2  cdecs,  mvaHPst{sig i)  h  sig'^  =  sig'2 
cdecs  h  {mvar-.sig i) .sig'i  =  nP^''(mcar:si52)-'S*52 


(8.113) 


cdecs  h  Fst(si5i)  =  Fst(si52) 

cdecs,  mvaH:fst{sigi)  h  5{mvaH  :  sig^)  =  5{mvaH  :  sig2) 
cdecs  h  p{mvar).sigi  :  Sig  cdecs  h  p{mvar).sig2  ■  Sig 
cdecs  h  p{mvar).sigi  =  p{mvar).sig2 


(8.114) 


cdecs  \-  sig  I  =  sig  2 
cdecs  h  maybe(si5i)  =  maybe(si5'2) 


(8.115) 
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Signature  Subtyping 


h  cdecs  ok 
cdecs  h  •  <  • 


cdecs  h  Idecs  <  Idecs' 


(8.116) 


cdecs  h  knd  <  knd' 

cdecs,  cvar-.knd  h  Idecs  <  Idecs'  cdecs,  cvar-.knd'  h  Idecs'  ok 
cdecs  h  lab>cvar:knd,  Idecs  <  lab>cvar:knd' ,  Idecs' 

cdecs  h  con  =  con'  ;  T  cdecs  h  Idecs  <  Idecs' 
cdecs  \-  lab>evar:con,  Idecs  <  lab\> evar: con' ,  Idecs' 


(8.117) 

(8.118) 


cdecs  h  sig  <  sig' 

cdecs,  mvaNTst{sig)  Idecs  <  Idecs'  cdecs,  mvar^:fst{sig')  h  Idecs'  ok 
cdecs  h  lab>mvar:sig,  Idecs  <  lab>mvar:sig' ,  Idecs' 


(8.119) 


cdecs  h  Idecs  <  Idecs' 
cdecs  h  pdecs]  <  [/decs'] 


cdecs  h  sig  <  sig' 


(8.120) 


cdecs  h  sigi  =  sig2  cdecs,  mvar'^-.sigi  h  sig'^  <  sig'2 
cdecs  h  IT°^{mvar-.sigi).sig'i  <  IT°^{mvar\sig2).sig'2 


(8.121) 


cdecs  h  sigi  =  sig2  cdecs,  mvar'^-.sigi  h  sig'^  =  sig'2 
cdecs  h  {nivar\sig i) .sig'i  <  {nivar:sig2) ■sig'2 


(8.122) 


cdecs  h  Fst(si5i)  ^  ^51(5/52) 

cdecs,  mvar^:fst{sigi)  h  5{mvar'^ :  sig^)  <  S(mvaN  :  5/^2) 
cdecs  h  p{mvar).sigi  :  Sig  cdecs  h  p{mvar).sig2  ■  Sig 
cdecs  h  p{mvar).sigi  <  p{mvar).sig2 


(8.123) 


cdecs  k  sig  I  <  sig  2 
cdecs  h  maybe(si5i)  <  maybe(si5'2) 


(8.124) 


Well-formed  Modules 


h  decs  ok 
decs  k  •  Ik  ' 


decs  h  Ibnds  Ideas 


(8.125) 


decs  h  bnd  dec  decs,  dec  h  Ibnds  Idecs 


decs  h  lab\>bnd,  Ibnds  lab>dec,  Idecs 


(8.126) 
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h  decs  ok  mvar:sig  €  decs 
decs  h  mvar  ;p  sig 

decs  h  Ibnds  Idecs 

decs  h  \lhnds]  |Zdecs] 


decs  h  mod  sig 


(8.127) 

(8.128) 


decs  h  pmod  :p  ,  labi>vari:sigi,  ■  ■  •] 
decs  h  pmod.labi  :p  sigilpmod.labj/varjYj^^ 

decs,  mvar:sig  h  mod  :p  sig' 
decs  h  {mvar: sig). mod  :p  IV-°^ {mvar: sig). sig' 

decs,  mvar: sig  h  mod  :k  sig' 
decs  h  AP^''(m?;ar:si5');si5'.mocZ  :p  {mvar: sig). sig' 

decs  h  mod  H^°^{mvar:sig').sig  decs  h  pmod'  :p  sig' 

decs  h  mod^°^{mod')  sig[pmod' / mvar] 

decs  h  mod  {mvar: sig'). sig  decs  h  pmod'  :p  sig' 

decs  h  mod'^^' {mod')  :i  sig{pmod' / mvar] 

decs  h  mod  sig 
decs  h  mod  :  >p  sig  sig 

decs  h  mod  sig 
decs  h  mod  :>i  sig  ij  sig 


(8.129) 

(8.130) 

(8.131) 

(8.132) 

(8.133) 

(8.134) 

(8.135) 


decs  h  sig  :  Sig  decs  h  exp  :  {|sigD 
decs  h  unpack  exp  as  sig  :i  sig 


(8.136) 


decs  h  mod  tsig 
decs  h  purify(mod)  :p  tsig 


(8.137) 


decs  h  modi  '-k  sigi  decs,  mvar:sigi  h  mod2  sig  decs  h  sig  :  Sig 
decs  h  let  mvar=modi  in  {mod2  :  sig)  sig 

decs  h  mod  sig 
decs  h  roll(morf)  :k  p{sig) 

decs  h  pmod  :p  p{mvar).sig 
decs  h  ur\ro\\{pmod)  :p  sig[pmod / mvar] 

decs  h  mod  maybe(sig') 
decs  h  fetch(mod)  sig 

decs,  mvar:maybe{tsig)  h  mod  :p  tsig 
decs  h  rec{mvar:tsig .mod)  :p  tsig 


(8.138) 

(8.139) 

(8.140) 

(8.141) 


(8.142) 
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decs  h  pmod  sig 
decs  h  pmod  :p  5 {pmod  :  sig) 

decs  h  mod  ;p  sig 
decs  h  mod  ;i  sig 

decs  h  mod  sig'  decs  h  sig'  <  sig 
decs  h  mod  sig 


(8.143) 

(8.144) 

(8.145) 


8.4  IL  Dynamic  Semantics 

As  in  the  simplified  IL,  the  dynamic  semantics  is  only  defined  for  the  core  language.  As  the  module 
language  of  the  actual  IL  is  almost  identical  to  that  of  the  simplified  IL,  adapting  the  phase-splitting 
translation  of  Sections  4.2.7  and  6.4  to  the  present  setting  is  completely  straightforward. 


::=  (cjjC,  exp) 

I  Error 
C  ::=  • 

I  CoT 

T  ::=  let  evar=  •  in  exp 
I  rec{evar:con.») 

I  handle  •  with  ua/ 

Let  D  denote  a  continuation  stack  that  does  i 


normal  machine  state 
error  state 

empty  continuation  stack 
non-empty  continuation  stack 
sequencing  frame 
recursive  backpatching  frame 
exception  handling  frame 

it  contain  any  exception  handling  frames. 


Small-Step  Operational  Semantics 


(cj,  C,  TTiab  {rbnds,  lab=val,  rbnds'})  i— >  {u>,  C,  val) 


0  I— » 

(8.146) 


fbnds  =  {evar'^{evari\coni)\eon'~expj)'^^i 
{to,  C,  {I\Xk  fbnds  end) (val))  (w,  C,  exp j^[val/evarb;][f\Xi  fbnds  end / evar'fff^]) 


(8.147) 


(w,  C,  handle  exp  with  val)  i— >  (cj,  C  o  handle  •  with  val.,  exp) 


{lo,  C  o  (handle  •  with  val'),  val)  (a;,  C,  val) 


{u),  C  o  (handle  •  with  val')  o  V,  raise™”  val)  {uj,  C,  val'  val) 


(8.148) 

(8.149) 

(8.150) 


{uj,T>,  raise™”  val)  ^  Error 
evar  ^  dom(u;) 

{uj,C,re^  val)  i— >  {uj[evar ^ val],  C,  evar) 


(8.151) 

(8.152) 
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evar  €  doin(L(j)  u’(evar)  =  val 
{to,  C,  get  evar)  i— >  (w,  C,  val) 

evar  G  dom(t(;) 

(to ,  C ,  set  {evar ,  val))  {uj[evar:=val],C,  {}) 


(8.153) 

(8.154) 


(ti;,C,  unfold“"((fold“”'((?;a/)))))  (w,C,  w/) 


(8.155) 


{uj,C,  {A{evar:knd).vexp)[con])  {u ,  C ,  vexp[eon / evar]) 


(8.156) 


{lo,  C,  case val  of  {labii-^vali)^^^  end)  {uj,C,  val^  val) 
evar  ^  dom(t(;) 

(w,  C,  new_tag[con])  {uj[evari-^7],C,  evar) 


(8.157) 

(8.158) 


{(jj,  C,  iftagof  tag(emr,  val)  is  evar  then  val'  else  exp)  (cu,  C,  val'  val) 

evar  7^  evar' 

(uj,C,  iftagof  tag(emr,  val)  is  evar'  then  val'  e\se  exp)  ^  (uj,C,  exp) 


(8.159) 

(8.160) 


(uj,C,  let  [evar,  evar]  =  unpack  (pack  [con,  val]  as  eon')  in  {exp  :  con"))  1— > 
{oj,C,  exp[con / cvar][val / evar]) 


(8.161) 


(ti;,C,let  cvar=con\n  exp)  1-^  {(jJ ,  C ,  exp[eon / evar]) 


{co,C,  let  evar=exp'  in  exp)  ^  {uJ,C  o  let  evar=  •  in  exp,  exp') 


(8.162) 

(8.163) 


{00,  C  o  let  evar=  •  in  exp,  val)  1-^  {uJ,C,  exp[val / evar]) 
evar  0  dom(u;) 

{u},C,rec{evar:con.exp))  1-^  {cv[evari-^7],C  o  rec{evar:con.»),  exp) 

evar  G  dom(t(;) 

{(jj,C  o  rec{evar:con.»),  val)  1-^  {io[evar:=val],  C ,  val) 

evar  G  dom(t(;)  uj{evar)  =  val 
(w, C,  fetch(euar))  1-^  {uj,C,val) 

evar  G  dom(t(;)  Lv{evar)  =  ? 
(ti;,C,fetch(e?;ar))  1-^  Error 


(8.164) 

(8.165) 

(8.166) 

(8.167) 

(8.168) 


Chapter  9 


Evolving 


the  ML  External  Langnage 


With  the  internal  language  type  system  in  hand,  I  can  now  define  my  external  language.  The  main 
goal  of  the  external  language  is  to  make  life  easier  for  the  programmer.  Thus,  like  Standard  ML, 
which  serves  as  the  external  language  in  Harper  and  Stone’s  framework  (HS),  my  language  supports 
type  inference,  pattern  matching,  datatype  definitions,  coercive  signature  matching,  etc.  These  are 
features  of  convenience,  not  necessity.  The  main  departure  from  this  view  of  the  external  language 
is  in  the  recursive  module  extension.  As  explained  in  Section  5.4,  my  elaboration  translation 
for  recursive  modules  supports  data  abstraction  between  recursive  modules  in  a  manner  that  is 
considerably  more  sophisticated  than  what  is  available  in  the  internal  language  type  system. 

My  external  language  is  based  closely  on  the  syntax  and  semantics  of  Standard  ML.  It  extends 
SML  with  support  for  higher-order  modules,  total  and  partial  functors,  basic  and  impure  sealing, 
the  packaging  (and  unpackaging)  of  modules  as  first-class  values,  recursive  modules  and  recursively 
dependent  signatures.  However,  it  is  not  a  conservative  extension: 

•  There  are  a  number  of  minor  syntactic  differences.  For  example,  following  O’Caml,  I  have 
chosen  to  replace  structure  and  functor  bindings  with  a  single  module  binding  form.  In  an 
actual  implementation,  it  may  be  desirable  to  also  support  the  SML  syntax  for  purposes  of 
backward  compatibility,  but  I  will  ignore  such  concerns  here. 

•  There  are  some  features,  such  as  type  and  structure  sharing  constraints  on  signatures,  that 
I  have  chosen  to  interpret  in  a  different  manner  than  SML  does,  because  I  find  the  SML 
semantics  to  be  problematic.  I  discuss  the  reasons  for  such  instances  of  semantic  divergence 
at  the  appropriate  points  in  the  chapter. 

•  There  are  some  features  of  SML,  such  as  infix  declarations,  that  affect  parsing  but  are  not 
interesting  from  a  semantic  point  of  view.  Following  HS,  my  elaboration  translation  assumes 
that  source-level  programs  have  already  been  parsed  into  the  abstract  syntax  of  the  external 
language,  so  I  do  not  bother  to  account  for  such  parsing-related  features. 

•  There  is  one  feature  of  Standard  ML  that  I  have  chosen  not  to  support  at  all  in  my  language, 
namely  the  overloading  of  the  equality  operator.  I  assume  that  equality  operators  are  defined 
for  some  fixed  set  of  base  types,  and  do  not  permit  equality  tests  at  other  types.  In  my 
experience  programming  in  SML  and  working  on  the  TILT  compiler,  I  have  found  overloaded 
equality  to  be  of  little  use,  yet  it  disproportionately  complicates  the  semantics  of  the  language. 
Incorporating  a  general  form  of  overloading  into  ML  (using  type  classes,  for  instance  [25])  is 
a  worthwhile  endeavor,  but  it  is  beyond  the  scope  of  this  thesis. 
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As  in  HS,  the  elaboration  translation  is  defined  by  a  set  of  judgments,  whose  inference  rules  are 
presented  in  declarative  fashion  but  admit  an  algorithmic  interpretation.  The  primary  judgments 
have  the  form 

r  h  EL-phrase  IL-phrase  :  IL-classifier 

where  the  context  T  and  EL-phrase  may  be  viewed  as  inputs,  and  IL-phrase  and  IL-classifier 
as  outputs.  For  some  auxiliary  judgments,  the  inputs  and  outputs  are  slightly  less  obvious.  In 
Section  9.2,  I  describe  how  to  interpret  all  the  elaboration  judgments,  and  I  also  stipulate  several 
invariants  that  are  assumed  and  maintained  by  the  elaboration  rules.  Some  of  these  invariants  are 
described  rather  informally.  For  instance,  if  you  see  a  module  containing  a  field  labeled  “tag,”  then 
that  module  must  be  the  output  of  elaborating  an  exception  binding. 

The  most  basic  invariant,  which  I  do  state  formally  in  Section  9.2,  is  soundness  of  the  trans¬ 
lation:  if  elaboration  succeeds,  it  generates  well-formed  output  (assuming  in  some  cases  certain 
preconditions  on  the  input).  Soundness  is  proved  by  straightforward  induction  on  the  elaboration 
rules.  While  I  attest  to  having  checked  soundness  for  every  rule,  the  sheer  quantity  and  complexity 
of  the  elaboration  rules  prevents  me  from  having  total  conhdence  that  I  have  not  overlooked  some 
bug,  serious  or  otherwise.  In  the  process  of  preparing  these  rules,  I  uncovered  many  bugs  in  the 
original  HS  elaboration  translation,  and  it  is  quite  possible  that  my  revisions  and  extensions  have 
introduced  new  ones.  Formalizing  HS  in  the  meta-logical  framework  Twelf  [63],  so  that  soundness 
may  be  checked  mechanically,  is  a  topic  of  current  research  at  CMU. 

Another  desirable  property  is  that  elaboration  be  deterministic.  Unfortunately,  due  to  type 
inference  this  is  not  the  case.  For  instance,  an  underconstrained  EL  phrase  such  as  fn  x  =>  x  may 
elaborate  to  an  identity  function  at  any  type,  con  con — the  generalization  to  the  polymorphic 
type  y{cvar:T).cvar  cvar  only  occurs  once  the  function  is  bound  to  a  variable.  HS  argue  infor¬ 
mally  that  this  element  of  nondeterminism  is  acceptable  because  valid  outputs  for  the  same  input 
should  only  differ  in  ways  that  do  not  affect  evaluation.  As  my  extensions  and  revisions  do  not 
introduce  any  new  sources  of  nondeterminism  beyond  what  is  already  present  in  HS  elaboration,  I 
refer  the  reader  to  HS  for  further  discussion  of  this  point. 

The  chapter  is  structured  as  follows;  In  Section  9.1, 1  present  the  syntax  of  my  external  language. 
In  Section  9.2,  I  give  an  overview  of  the  judgments  that  comprise  the  elaboration  translation,  their 
interpretations  and  their  soundness  properties.  In  Section  9.3,  I  dehne  the  translation  itself.  Finally, 
in  Section  9.4,  I  discuss  the  implementation  of  a  variant  of  this  external  language  that  I  undertook 
in  the  context  of  the  TILT  compiler. 

9.1  EL  Syntax 

The  syntax  of  the  external  language  is  shown  in  Figures  9.1  and  9.2.  Optional  elements  are  enclosed 
in  angle  brackets  (•  •  •).  All  optional  choices  are  independent.  Some  points  of  note: 

•  I  assume  the  existence  of  several  (disjoint)  base  syntax  classes,  including:  base  (a  fixed 
set  of  base  types,  including  int,  float,  unit,  etc.),  scon  (syntactic  constants,  same  as  in 
the  IL),  tyvar  (type  variables),  reclab  (record  labels),  expid  (term  identifiers),  conid  (type 
constructor  identifiers),  modid  (module  identifiers),  and  sigid  (signature  identifiers).  For 
id  G  {expid,  conid,  modid},  there  is  a  corresponding  “long”  class  longid,  defined  as 

longid  :;=  id  \  modid.  longid 

•  Tuple  types  (of  length  n)  are  not  supported  explicitly,  but  are  encodable  as  record  types 
whose  components  are  labeled  1  to  n.  (The  class  of  reclab’ s  includes  the  natural  numbers.) 
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ty  ::= 

expr  ::= 


bindings  ::= 
binding  ::= 


funbinds  ::= 
tybind  ::= 
branches  ::= 
datbind  ::= 
datbinds  :;= 


base 

tyvar 

{reclabi  :  ty^ ,  ■  ■  ■  ,reclabn  :  ty^} 
ty  ->  ty' 

(tyi ,  •  •  •  NUn'^  {modexp  .) conid 

scon 

expid 

modexp .  expid 

{reclabi  =  expri,  •  •  •  ,reclabn  =  expr^} 
let  bindings  in  expr  end 
expr  expr' 
expr  :  ty 

expr  handle  match 
raise  expr 
fn  match 

pack  modexp  as  longconid 


binding  { ; )  bindings 

val  (tyvar I ,  •  •  •  ,  tyvar pat  =  expr 

fun  (tyvar I ,  ■  ■  ■  ,  tyvar funbinds 

open  longmodid I  ■■■  longmodid^ 

exception  expid 

exception  expid  of  ty 

exception  expid  =  longexpid 

local  bindingsi  in  bindings2  end 

type  tybind 

datatype  datbinds 

datatype  conid  =  datatype  longconid 
packtype  conid  =  sigexp 
signature  sigid  =  sigexp 
module  modid  =  modexp 

expid  =  fn  match  (and  funbinds) 

(tyvar I ,  •  • •  ,  tyvar conid  =  ty 
expid  (of  ty)  { I  branches) 

(tyvar I ,  •  • •  ,  tyvar conid  =  branches 
datbind  I  (and  •••  and  datbind  n) 
(withtype  tybind^  and  •  •  •  and  tybind.^) 


Figure  9.1;  Syntax  of  the  External  Language 
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match  :: 

mrule  :: 
pat  :: 


sigexp  :: 

specs  :: 
spec  :: 


seal  :: 

modexp  :: 


mrule 

mrule  I  match 
pat  =>  expr 
scon 

longexpid 

pat  :  ty 
longexpid  pat 

ireclabi  =  pati ,  ■  ■  ■  ,  reclabn  =  patn{,  •  •  • )} 
pati  as  pat2 
ref  pat 

sigid 

sig  specs  end 

functor  imodid  :  sigexp)  ->  sigexp' 
functor  imodid  :  sigexp)  -»  sigexp' 
rec  imodid)  sigexp 

sigexp  where  type  ityvari,  •  •  •  ,tyvar^)  longconid  =  ty 
spec  specs 

val  ityvari,  •••  ,tyvar^)  expid  :  ty 
type  ityvari ,  •  • •  ,  tyvar^)  conid 
type  ityvari ,  ■  ■  ■  ,  tyvar^)  conid  =  ty 
datatype  datbinds 

datatype  conid  =  datatype  longconid 
packtype  conid  =  sigexp 
exception  expid 
exception  expid  of  ty 
module  modid  :  sigexp 
include  sigexp 

specs  sharing  type  longconid i  =  longconid2 
specs  sharing  longmodidi  =  longmodid2 

:  > 

: » 

modid 

struct  bindings  end 
modexp .  modid 

functor  imodid  :  sigexp)  ->  modexp 

functor  imodid  :  sigexp)  -»  modexp 

modexp  I  imodexp2) 

let  bindings  in  modexp  end 

modexp  seal  sigexp 

unpack  expr  as  longconid 

rec  imodid  :  sigexp)  modexp 


Figure  9.2;  Syntax  of  the  External  Language  (continued) 
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•  Unlike  in  SML,  types,  terms  and  modules  may  be  projected  from  arbitrary  module  expres¬ 
sions  modexp,  not  just  from  longmodid'’s.  While  the  elaboration  translation  places  restrictions 
on  which  modules  may  be  projected  from,  they  are  not  simple  syntactic  restrictions.  Never¬ 
theless,  there  are  several  instances  in  the  syntax  where  a  type  is  required  to  have  the  form 
longconid  or  a  module  is  required  to  have  the  form  longmodid  {e.g.,  in  sharing  constraints  on 
signatures).  The  typical  reason  for  making  such  a  restriction  is  to  ensure  that  the  translation 
of  the  type  or  module  has  a  certain  form  {e.g.,  see  Rule  9.25). 

•  In  much  the  same  way  that  recursive  and  sum  types  are  accessible  to  the  SML  programmer 

only  through  the  datatype  mechanism,  existential  types  are  accessible  to  the  programmer  of 
my  language  only  through  the  packtype  mechanism.  The  binding  packtype  conid  =  sigexp 
elaborates  to  a  module  containing  three  components:  (1)  an  abstract  type  conid,  implemented 
internally  as  where  sig  is  the  IL  translation  of  sigexp,  (2)  a  functor  named  conid _pack, 

which  takes  modules  of  signature  sig  and  packages  them  as  values  of  type  conid,  and  (3)  a 
functor  named  conid_  unpack,  which  unpackages  values  of  type  conid  into  modules  of  sig¬ 
nature  sig.  Correspondingly,  the  EL  term  pack  modexp  as  longconid  and  the  EL  module 
unpack  expr  as  longconid  package  modexp  and  unpackage  expr,  respectively,  by  applying 
to  them  the  “pack”  and  “unpack”  functors  located  in  the  module  defining  longconid.  The 
purpose  of  hiding  the  implementation  of  conid  behind  an  abstract  interface  is  to  permit  the  in¬ 
troduction  of  package  types  into  the  language  without  affecting  the  type  inference/unification 
algorithm. 

•  Like  HS  and  unlike  the  Definition  of  SML,  I  do  not  distinguish  between  top-level  bindings 

and  module  bindings.  There  is  only  one  kind  of  binding  (HS  use  the  term  strdec  instead). 
Following  O’Caml,  I  replace  structure  and  functor  bindings  with  a  single  module  binding 
form.  I  also  introduce  anonymous  functor  expressions  functor  (modid  :  sigexp)  ->  modexp 
and  functor  {modid  :  sigexp)  -»  modexp,  where  the  former  denotes  a  total  functor  and  the 
latter  a  partial  functor.  I  similarly  distinguish  between  total  and  partial  functor  signatures 
by  writing  the  former  with  a  arrow  and  the  latter  with  with  a  arrow.  SML’s 

functor  binding  may  be  encoded  as  a  module  binding  of  a  partial  functor  expression. 

•  The  language  supports  three  forms  of  sealing;  transparent  (:),  basic  (:>)  and  impure  (:»). 
Transparent  sealing  has  precisely  the  same  semantics  as  in  SML  (see  the  note  on  Rule  9.52 
for  details).  The  latter  two  correspond  directly  to  :>p  and  :>i  in  the  IL,  respectively.  The 
notation  is  perhaps  slightly  unfortunate  here.  As  explained  in  Section  2.2.1,  although  basic 
sealing  is  denoted  here  in  the  same  way  that  opaque  sealing  is  denoted  in  SML,  SML’s  opaque 
sealing  is  in  fact  closer  semantically  to  impure  sealing  (:>>).  Nonetheless,  for  uniformity,  I 
have  chosen  to  mark  the  distinction  between  basic  and  impure  sealing  using  the  same  >/» 
motif  used  to  distinguish  the  total  and  partial  forms  of  functors  and  functor  signatures. 

•  I  assume  that  all 

—  tyvaYs  appearing  in  a  single  sequence  (tyvari ,  •  •  •  ,  tyvar^^) 

—  reclab's  in  a  record  expression,  record  pattern,  or  record  type 

—  expid's  bound  in  a  single  f unbinds 

—  conid^s  and  expid's  bound  in  a  single  datbinds 
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9.2  Overview  of  Elaboration 


9.2.1  Preliminaries 

•  I  assume  the  existence  of  an  injective  overbar  function  ~  mapping  each  EL  identifier  to  an 
IL  label.  This  function  can  also  be  applied  pointwise  to  a  “long”  identifier,  resulting  in  a 
sequence  of  labels  (separated  by  dots),  called  labs.  I  will  also  assume  the  existence  of  an 
infinite  set  of  “internal”  labels  that  are  not  in  the  range  of  the  overbar  function.  There  is  a 
fixed  subset  of  the  internal  labels  that  the  elaborator  uses  to  recognize  certain  elaboration 
idioms.  These  known  labels  include  “it” ,  “in” ,  “out” ,  “pack” ,  “unpack” ,  “hidden” ,  “visible” , 
“tag”,  “fail”,  and  the  natural  numbers.  I  will  denote  all  other  internal  labels  by  ilab. 

•  A  label  lab  may  be  “opened”  by  writing  lab*.  Open  labels  are  used  to  mark  certain  modules 
that  are  “open”  for  identifier  lookup.  (See  the  discussion  of  the  lookup  rules  below  for  details.) 
One  may  also  join  two  labels  labi  and  lab2  to  form  a  new,  internal  label  labi_lab2.  If  a  label 
is  the  result  of  joining,  it  may  be  deconstructed  into  its  component  parts.  Joining  of  labels  is 
useful  in  the  elaboration  of  datatype  and  packtype  bindings. 


•  The  elaborator  maintains  a  typing  context  T  that  is  essentially  a  list  of  labeled  declarations 
(Idecs),  except  for  two  generalizations:  (1)  the  list  may  contain  duplicate  labels  (but  not 
duplicate  variables),  and  (2)  it  may  also  contain  declarations  of  the  form  sigid=sig  for  the 
purpose  of  elaborating  EL  signature  bindings.  The  labels  on  the  declarations  in  T  are  used 
to  map  EL  identifiers  to  corresponding  IL  variables. 

I  will  write  IL(r)  to  denote  the  erasure  of  the  elaboration  context  E  into  an  IL  context 
decs,  which  simply  strips  off  the  labels  on  all  the  Idee  entries  in  T,  and  erases  all  the  signature 
declarations.  I  will  take  “  h  T  ok”  to  mean  that  h  IL(r)  ok  and,  for  all  signature  declarations 
sigid=sig  in  T,  we  have  IL(r)  h  sig  :  Sig.  Eor  all  other  IL  judgments  N,  I  will  take  “T  h  N” 
to  mean  that  h  T  ok  and  IL(r)  h 


•  It  is  useful  to  work  with  a  subclass  of  signatures,  called  static  signatures  and  denoted  by  the 
metavariable  statsig,  whose  distinguishing  characteristic  is  that  they  do  not  contain  any  value 
or  partial  functor  declarations.  In  essence,  one  may  view  a  static  signature  as  a  kind  that  has 
been  promoted  to  the  status  of  a  signature.  Eormally,  static  signatures  and  declarations  are 
defined  by  the  following  grammar: 


statsig  ::= 


{statldecs} 

( mvar  -.statsig).  statsig' 
p{statsig) 
m  ay  be(  statsig) 


statldec  ::= 
statdec  ::= 


lab>statdec 
cvar-.knd 
mvar -.statsig 


Any  signature  can  be  erased  into  a  static  signature  by  the  following  Stat(-)  function: 


Stat(sig) 

Stat(|Wecs])  =  |Stat(/decs)] 

Stat{lT°^  (mvar-.sig)  .sig')  =  IT°^  {mvar:Stat{sig))  .Stat(sig') 

(mvar  :sig). sig')  =  [-J 

Stat{p{mvar).sig)  =  p(Stat(sig)) 

Stat(maybe(sig))  =  maybe(Stat(sig)) 

Stat(/decs) 

Stat(-)  =  • 

Stat{lab>cvar:knd,  Ideas)  =  lab>cvar:knd,Stat{ldecs) 
Stat{lab>evar:con,  Ideas)  =  Stat(Wecs) 

Stat{lab>mvar:sig,  Ideas)  =  lab> mv ar :Stat (sig),  Stat (Ideas) 
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One  can  view  the  Stat(sig')  function  as  doing  half  the  work  of  the  fst{sig)  function.  It 
eliminates  the  “dynamic”  part  of  sig,  but  does  not  go  the  extra  step  of  turning  the  signature 
into  a  kind.  During  elaboration,  Stat(si5)  is  often  easier  to  work  with  than  Fst(sig)  because 
static  signatures  are  amenable  to  certain  operations  {e.g.,  looking  up  a  label  in  a  signature) 
that  are  not  defined  for  kinds.  Here  are  some  useful  properties  of  the  Stat(-)  function: 

1.  If  cdecs  h  sig  :  Sig,  then  cdecs  h  Stat(si5)  :  Sig  and  cdecs  h  fst{sig)  =  Fst(Stat(si5)). 

2.  If  cdecs  h  sigi  =  sig2,  then  cdecs  h  Stat(sig';^)  =  Stat(sf(72)- 

3.  If  cdecs  h  sigi  <  sig2,  then  cdecs  h  Stat(sig';^)  <  Stat{sig2). 

•  I  write  vpmod  to  denote  a  pmod  that  is  also  a  vmod,  i.e.,  a  module  expression  that  is  both 
projectible  and  valuable.  I  write  phrase  to  denote  something  that  is  either  a  con,  exp  or  mod. 
I  write  elass  to  denote  something  that  is  either  a  knd,  con  or  sig. 

•  As  explained  in  Section  5.4,  the  first  phase  of  recursive  module  elaboration  generates  some¬ 
thing  I  call  a  meta- signature,  which  encapsulates  the  type  information  that  is  known  at 
different  points  during  the  typechecking  of  the  recursive  module.  Meta-signatures  have  the 


following  grammar: 

metasig  ::= 

\metaldecs\ 

metaldee  ::= 

lab>metadec 

1 

( mvar-.sig) .  metasig' 

metadee  ::= 

evar-.knd 

p{mvar). metasig 
{private=sig]^,  public=si5'2} 

evar:eon 

mvar -.metasig 

The  one  case  that  distinguishes  metasig's  from  ordinary  sig's  is  {private=sf5]^, public=si5'2}- 
I  call  this  a  “switchable”  signature  because  it  provides  a  way  for  the  recursive  module  elabo¬ 
ration  algorithm  to  switch  between  public  and  private  views  of  a  module  when  typechecking 
different  parts  of  the  recursive  module  body. 

The  functions  Priv(-)  and  Pub(-)  erase  meta-signatures  into  ordinary  signatures  by  switching 
all  switchable  signatures  to  either  the  private  or  the  public  setting,  respectively: 


Pm{metasig) 

Priv([mefaWecs])  =  |Priv(metaWecs)] 

Pm  {11^°^  [mvar -.sig). metasig')  =  11^°^  [mvar -.sig). Pm  [metasig') 

Pm[p[mvar). metasig)  =  p[mvar). Pm  [metasig) 

Priv({private=sz5i,  public=sf52})  =  sigi 

Pm{metaldecs) 

Priv(-)  =  • 

P m[lab> evar-.knd,  metaldecs)  =  lab>cvar:knd,Pm[metaldecs) 

Pm[lab>evar:con,  metaldecs)  =  lab>evar:con,Pm[metaldees) 

Pm[lab>mvar:metasig,  metaldees)  =  lab>mvar:Pm [metasig), 

Pm[metaldecs) 

Puh{metasig) 

Pub([metaWecs])  =  |Pub(TOetaWecs)] 

Pub[lT°^  [mvar:sig)  .metasig')  =  lT°^[mvar:sig).Pub[metasig') 

Pub[p[mvar)  .metasig)  =  p[mvar). Pub  [metasig) 

Pub({private=si5i,  public=sf52})  =  sig2 

Pub{metaldecs) 

Pub(-) 

Pub[lab>evar:knd,  metaldecs)  =  lab>cvar:knd,Pub[metaldecs) 

Pub[lab>evar:con,  metaldecs)  =  lab>evar:  con.  Pub  [metaldecs) 

Pub[lab\>mvar:metasig,  metaldecs)  =  lab>mvar:Pub[metasig), 

Pub[metaldecs) 
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In  fact,  Pn\/ (metasig)  and  Pub{metasig)  are  just  two  possible  settings  of  metasig,  where  a 
“setting”  of  metasig  is  taken  to  mean  an  ordinary  signature  formed  by  replacing  each  switch- 
able  signature  in  metasig  of  the  form  {private=si5'^, public=si52}  with  either  sigi  or  sig2 
{i.e.,  setting  each  switch  to  “private”  or  “public”).  Before  observing  some  useful  properties 
of  meta-signatures  and  their  settings,  let  us  define  what  it  means  for  a  meta-signature  to  be 
well- formed  by  extending  the  existing  IL  judgments  for  signatures  and  declarations  with  the 
following  new  cases  for  meta-signatures  and  meta-declarations: 


cdecs  h  metasig  :  Sig 


cdecs  h  metaldecs  ok 

(9.1) 

cdecs  h  [metaldecs\  :  Sig 

cdecs  h  sig  :  Sig  cdecs,  mvaH:Pst{sig)  h  metasig'  :  Sig 

cdecs  h  IT°^{mvar:sig).metasig'  :  Sig 

(9.2) 

cdecs  h  Pst.{Pm{metasig))  :  Kind 

cdecs,  mvaN'.Pst{Puh[metasig))  h  metasig  :  Sig 
cdecs  h  p{mvar) .metasig  :  Sig 

(9.3) 

cdecs  P  sig  1  <  sig 2 

(9.4) 

cdecs  h  {private=si5;^,  public=si5'2}  :  Sig 

cdecs  h  metaldecs  ok 


cdecs  h  metadec  ok  cdecs,  Fst(Pub(metodec))  h  metaldecs  ok 
cdecs  h  lab>metadec,  metaldecs  ok 


cdecs  h  metadec  ok 


cdecs  h  metasig  :  Sig 
cdecs  h  mvar:metasig  ok 

These  well-formedness  rules  were  designed  in  order  to  guarantee  the  following  property: 

—  If  cdecs  h  metasig  :  Sig  and  sig  is  a  setting  of  metasig, 

then  cdecs  h  sig  :  Sig  and  cdecs  h  Pm{metasig)  <  sig  and  cdecs  h  sig  <  Puh{metasig) 
(in  particular,  cdecs  h  Pm{metasig)  <  Puh{metasig)). 

While  this  property  is  provable  by  straightforward  induction,  its  proof  depends  on  some  subtle 
points  in  the  above  rules.  In  Rule  9.2,  it  is  important  that  the  argument  in  the  functor  meta¬ 
signature  is  an  ordinary  signature,  since  functor  subtyping  is  invariant  in  the  argument.  In 
Rule  9.3,  the  first  premise  is  necessary  to  ensure  that,  for  any  setting  sig  of  metasig,  Pst{sig) 
does  not  refer  to  mvaP. 
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9.2.2  Guide  to  the  Elaboration  Judgments 

In  this  section,  I  describe  at  a  high  level  what  each  elaboration  judgment  means,  how  it  is  used, 
what  its  soundness  properties  are,  and  (in  some  cases)  what  its  output  may  be  expected  to  look 
like.  Note:  the  soundness  properties  for  all  the  rules  assume  that  the  given  typing  context  F  (or  in 
some  cases  decs)  is  well- formed. 

Main  Translation  Jndgments 

•  T  \-  ty  con  :  T 

—  Interpretation:  Given  an  EL  type  {ty),  return  its  translation  as  an  IL  type  {con). 

—  Soundness:  F  h  con  :  T. 

•  F  h  expr  exp  :  con 

—  Interpretation:  Given  an  EL  term  (expr),  return  its  translation  as  an  IL  term  (exp) 
and  its  type  (con). 

—  Soundness:  F  h  exp  :  con. 

•  F  h  match  ^  val  :  con 

—  Interpretation:  Given  an  EL  pattern  match  (match),  return  a  function  val  (of  type 
con)  that  takes  an  argument  of  the  type  expected  by  match,  tries  to  match  the  argument 
against  each  of  the  mrule'’s  in  the  match  (in  order),  and  throws  a  “fail”  exception  if  the 
pattern  match  fails. 

—  Soundness:  F  h  val  :  con. 

—  Comments:  The  “fail”  exception  is  a  component  of  the  “basis”  module  that  may  be 
assumed  bound  in  F  (see  Section  9.3.1  for  details). 

•  F  h  binding{s)  Ibnds  Ik  Idecs 

—  Interpretation:  Given  EL  binding (s),  return  their  translation  as  a  sequence  of  IL 
labeled  bindings  (Ibnds),  along  with  a  matching  sequence  of  labeled  declarations  (Idecs) 
that  describe  them,  k  is  the  purity  level  of  the  Ibnds. 

—  Soundness:  F  h  Ibnds  Idecs. 

—  Comments:  The  labels  on  the  output  Ibnds  fall  into  two  general  categories:  (1)  they 
have  the  form  id,  where  id  is  the  EL  identifier  bound  by  the  corresponding  input  binding, 
or  (2)  they  have  the  form  ilab* ,  where  ilab  is  an  arbitrary  internal  label.  In  the  latter  case, 
the  elaborator  understands  the  binding  to  mean  that  the  module  labeled  ilab*  should 
be  considered  “open.”  That  is,  the  elaborator  treats  the  components  of  the  module  as 
if  they  were  bound  at  top  level  alongside  the  other  category- 1  Ibnds. 

•  F  h  modexp  ^  mod  sig 

—  Interpretation:  Given  an  EL  module  expression  (modexp),  return  its  translation  as  an 
IL  module  (mod),  along  with  its  principal  signature  (sig)  and  purity  level  k. 

—  Soundness:  F  h  mod  sig. 
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—  Comments:  As  explained  in  Section  4.2.6,  I  follow  HS’s  approach  to  addressing  the 
avoidance  problem.  For  example,  I  elaborate  the  EL  module  let  bindings  in  modexp  end 
into  the  IL  module  [hidden> mvar=[lbnds],  visible* = mod],  where  Ibnds  is  the  translation 
of  bindings  and  mod  is  the  translation  of  modexp.  The  “hidden”  label  ensures  that 
the  local  bindings  are  in  fact  kept  in  a  hidden  namespace,  because  no  EL  identifier  will 
be  translated  (by  the  overbar  function)  into  the  label  “hidden”.  In  contrast,  since  the 
visible*  label  on  the  second  component  is  open,  the  components  of  mod  will  be  accessible 
to  the  programmer.  Several  of  the  modexp  translation  rules  return  IL  modules  of  this 
same  form.  I  refer  to  such  modules  as  having  “existential”  signature  3{mvar:sig i).sig2, 
which  is  definable  as  [hiddenomuarisi^j^, visible*:si52l' 

•  r  h  spec{s)  Idecs 

—  Interpretation:  Given  EL  spec{s),  return  their  translation  as  a  sequence  of  IL  Idecs. 

—  Soundness:  F  h  Idecs  ok. 

—  Comments:  As  in  the  translation  of  bindings,  the  output  Idecs  here  fall  into  two 
categories;  those  with  labels  of  the  form  id  and  those  with  labels  of  the  form  ilab*. 
The  interpretation  of  the  latter  category  is  the  same  as  in  the  binding  translation:  the 
elaborator  treats  the  components  of  the  module  declared  with  label  ilab*  as  if  they  were 
declared  in  the  same  namespace  as  the  other  category- 1  Idecs. 

•  F  h  sigexp  ^  sig  :  Sig 

—  Interpretation:  Given  an  EL  signature  expression  (sigexp),  return  its  translation  as 
an  IL  signature  (sig). 

—  Soundness:  F  h  sig  :  Sig. 

•  T  iitat  spec(s)  statldecs 

E  bat  sigexp  ^  statsig  :  Sig 

—  Interpretation:  Same  as  the  normal  judgments  for  translating  specifications  and  sig¬ 
natures,  except  that  these  judgments  only  translate  the  static  part  of  the  input  (i.e., 
val  specs,  exception  specs,  etc.  are  ignored). 

—  Soundness:  F  h  statldecs  ok,  F  h  statsig  :  Sig. 

—  Comments:  These  judgments  are  useful  in  elaborating  recursively  dependent  signa¬ 
tures.  Given  an  EL  rds  of  the  form  rec  {modid)  sigexp,  we  ultimately  want  to  do  full 
elaboration  of  sigexp  into  an  IL  signature  sig.  Before  we  can  do  full  elaboration,  how¬ 
ever,  we  need  to  figure  out  what  Stat(sig')  is,  because  sigexp  is  only  well-formed  in  a 
typing  context  where  modid  has  signature  Stat(si5).  These  static  elaboration  judgments 
allow  us  to  compute  Stat(si5)  under  the  original  context  F  first,  without  worrying  about 
references  to  modid  in  the  dynamic  components  of  sigexp.  Although  soundness  does 
not  depend  on  it,  these  judgments  are  defined  so  that,  whenever  F  h  spec(s)  ^  Idecs 
(resp.  F  h  sigexp  sig  ;  Sig),  it  is  also  the  case  that  F  bat  spec(s)  ^  Stat(ldecs)  (resp. 
T  bat  sigexp  ^  Stat(sig)  :  Sig). 

•  F  h  pat  exp  :  con  else  val  ^  Ibnds  :  Idecs 

—  Interpretation:  Given  an  EL  pattern  (pat),  an  IL  expression  exp  of  type  con,  and 
an  exception  val  of  type  Tagged,  match  exp  against  the  pattern  pat.  This  results  in  a 
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bunch  of  IL  bindings  Ibnds  (described  by  Idecs),  which  bind  pattern  identifiers  to  the 
appropriate  projections  from  exp.  If  the  pattern  match  fails,  the  evaluation  of  Ibnds  will 
raise  the  exception  val. 

—  Soundness:  If  F  h  exp  :  con  and  F  h  val  :  Tagged,  then  F  h  Ibnds  Ideas.  Furthermore, 
Ibnds  is  a  sequence  of  term  bindings.  No  binding  refers  to  any  of  the  previous  bindings 
in  the  sequence. 

•  F  h  datbinds  ^  sig 

—  Interpretation:  Given  an  EL  datatype  specification  (datbinds),  return  an  IL  signature 
(sig)  describing  the  specified  types  and  their  data  constructors. 

—  Soundness:  F  h  sig  :  Sig. 

—  Comments:  Each  type  conid  specified  by  the  datbinds  will  be  accorded  its  own  (open) 
module  declaration.  In  that  module  declaration  will  be  specified:  (1)  the  type  itself  (with 
an  opaque  kind,  since  datatype’s  in  ML  are  abstract  types),  (2)  two  coercion  functions 
(conid -vn  and  conid -0\xt)  for  converting  between  conid  and  its  recursive  expansion, 
and  (3)  each  of  conid's  data  constructors.  Since  datatype  bindings/specifications  are 
the  only  places  where  the  “in”  and  “out”  labels  are  used,  a  number  of  rules  throughout 
the  elaborator  test  whether  a  given  type  named  lab  is  in  fact  a  datatype  by  checking 
whether  it  is  defined  in  the  same  module  as  a  value  labeled  lab— in. 

Canonical  Implementations  of  Signatures 

•  decs  Lean  sig  mod 

—  Interpretation:  Given  an  IL  signature  sig,  return  a  canonical  module  mod  of  that 
signature. 

—  Soundness:  decs  h  mod  :p  sig. 

—  Comments:  Canonical  implementations  exist  only  for  signatures  of  a  certain  restricted 
form.  Essentially,  the  input  signature  must  be  static  and  transparent — as,  in  general,  nei¬ 
ther  value  specifications  nor  opaque  type  specifications  have  canonical  implementations — 
the  only  exception  being  that  it  may  contain  module  declarations  that  correspond  to  the 
elaboration  of  datatype  specifications.  This  judgment  is  invoked  by  Rule  9.152  for 
recursive  module  elaboration  and  also  by  Rule  9.41  for  translating  datatype  bindings. 

Coercive  Signature  Matching 

•  decs  iiub  vpmod  :  sig^  ^  sig  pmod  ;  tsig 

—  Interpretation:  Given  a  projectible,  valuable  module  vpmod  of  signature  sigQ,  and  a 
target  signature  sig,  coerce  vpmod  into  sig.  The  coercion  module  pmod  (with  transparent 
signature  tsig)  will  copy  all  of  its  components  from  vpmod  but  have  the  shape  of  sig 
instead  of  sig^. 

—  Soundness:  If  decs  h  vpmod  sigQ  and  decs  h  sig  :  Sig,  then  decs  h  pmod  :p  tsig  and 
decs  h  tsig  <  sig. 

—  Comments:  Unlike  IL  subtyping,  coercive  signature  matching  permits  dropping  and 
reordering  of  structure  components,  allows  total  functors  to  be  coerced  to  partial  functor 
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signatures,  and  matches  functor  signatures  contravariantly  in  the  argument  and  covari- 
antly  in  the  result. 

•  decs  iiub  vpmod  :  sig^  ■<  ldec{s)  ^  plbnd{s)  :  tldec{s) 

—  Interpretation:  Given  a  projectible,  valuable  module  vpmod  of  signature  sigQ,  and 
target  specification(s)  ldec{s),  return  plbnd{s)  that  copy  the  corresponding  components 
from  vpmod  and  match  the  shape  of  the  ldec{s). 

—  Soundness:  If  decs  h  vpmod  :p  sigQ  and  decs  h  Idec(s)  ok,  then  decs  h  plbnd{s)  :p 
tldec{s)  and  decs  h  tldec{s)  <  ldec{s). 

Signature  Patching 

•  sig  hvt  ^dbs  :=  phrase  sig' 

—  Interpretation:  By  adding  to  the  signature  sig  the  fact  that  the  type  or  module 
component  selected  by  labs  is  statically  equivalent  to  phrase,  we  get  the  signature  sigh 

—  Comments:  This  judgment  is  used  in  the  translation  of  signatures  with  where  type 
constraints  (Rule  9.83).  It  does  not  guarantee  that  the  output  sig'  is  well-formed  or 
that  sig'  is  a  subtype  of  sig — Rule  9.83  verifies  this  independently.  The  judgment  simply 
traverses  sig  according  to  the  path  described  by  labs  and  then  replaces  whatever  classifier 
(class)  it  finds  there  by  5(phrase  :  class). 

•  sig  fih  labs  I  :=  labs2  ^  sig' 

—  Interpretation:  By  adding  to  the  signature  sig  the  fact  that  the  type  or  module 
component  selected  by  labsi  is  statically  equivalent  to  the  one  selected  by  labs  2,  we 
get  the  signature  sig'. 

—  Comments:  This  judgment  is  used  in  the  translation  of  type  sharing  and  structure 
sharing  constraints  (Rules  9.73  and  9.74).  Like  the  hvt  judgment,  it  does  not  guarantee 
that  the  output  sig'  is  well-formed  or  that  it  is  a  subtype  of  sig.  The  judgment  simply 
traverses  sig  according  to  the  path  described  by  the  common  prefix  of  labsi  and  labs2, 
and  then  it  invokes  the  hvt  judgment  to  finish  the  job.  It  only  succeeds  if  the  component 
indexed  by  labsi  appears  further  down  in  the  input  sig  than  the  one  indexed  by  labs  2 
(otherwise,  the  classifier  of  the  labsi  component  could  not  be  replaced  by  a  singleton 
referring  to  the  labs2  component). 

A  note  about  type  and  structure  sharing;  The  semantics  of  sharing  type  constraints  given  by 
the  Definition  of  SML  makes  a  subtle  distinction  between  “flexible”  and  “rigid”  type  components. 
Given  a  signature  sig,  a  flexible  type  is  one  that  sig  specifies  opaquely  or  that  it  specifies  as 
transparently  equal  to  some  other  type  that  sig  specifies  opaquely.  A  type  is  rigid  if  it  is  not 
flexible.  The  Definition  only  permits  sharing  of  two  flexible  types.  Thus,  the  signature 

sig  type  t  =  int  type  u  =  int  sharing  type  t  =  u  end 

is  not  considered  well- formed,  because  t  and  u  are  transparently  specified  to  equal  a  type  (int) 
not  specified  by  the  signature  and  are  therefore  rigid. 

The  Definition’s  restriction  to  sharing  flexible  types  was  put  in  place  to  prevent  type  sharing 
from  requiring  higher-order  unification.  While  the  restriction  is  not  a  problem  per  se,  it  becomes 
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problematic  because  of  the  way  the  Definition  defines  structure  sharing  constraints  in  terms  of 
type  sharing  constraints.  Specifically,  the  Definition  defines  a  sharing  constraint  on  two  structure 
components  of  a  signature  by  expanding  it  into  a  set  of  type  sharing  constraints,  one  for  every 
type  constructor  of  the  same  name  and  arity  provided  by  both  structures.  As  a  result,  even  if  two 
structures  are  specified  with  exactly  the  same  signature,  attempting  to  impose  a  sharing  constraint 
on  them  will  fail  if  that  signature  includes  even  one  rigid  type  specification.  Since,  in  my  experience 
structure  sharing  is  desired  almost  exclusively  for  sharing  two  structures  of  the  same  signature,  I 
find  the  Definition’s  semantics  of  structure  sharing  to  be  overly  restrictive. 

Different  implementations  of  SML  loosen  the  Definition  in  different  ways.  The  SML/NJ  compiler 
allows  any  two  structure  components  to  be  shared  if  they  are  specified  by  the  same  signature 
identifier.  The  TILT  compiler  employs  a  more  liberal  semantics  of  type  sharing  so  that  one  may 
share  two  rigid  type  components  so  long  as  they  are  transparently  equal  to  the  same  type. 

The  approach  I  have  taken  in  my  present  design  is  to  dispense  with  the  rigid /flexible  distinction 
entirely.  I  view  a  type/structure  sharing  constraint  as  simply  a  symmetric  way  of  asking  for  one 
of  the  components  to  be  assigned  a  singleton  kind/signature  referring  to  the  other.  The  constraint 
is  only  considered  valid  if  the  resulting  signature  is  an  IL  subtype  of  the  original  signature.  If 
the  types/structures  did  not  have  the  same  shape  to  begin  with,  then  the  sharing  constraint  may 
fail  under  my  semantics  but  not  under  the  Definition’s.  However,  as  the  vast  majority  of  sharing 
constraints  are  imposed  on  types/structures  of  exactly  the  same  kind/signature,  my  semantics  will 
in  most  realistic  cases  be  more  liberal  than  the  Definition’s. 

Signature  Peeling 

•  decs  h^eei  pmod:sig  pmod'  :  sig' 

—  Interpretation:  Given  a  module  pmod  of  signature  sig,  peel  off  the  outer  layers  of  sig 
until  we  reach  an  “interesting”  signature,  i.e.,  either  a  functor  or  structure  signature  sig' 
that  is  not  an  existential  signature  (not  of  the  form  |hiddeni>mr;ar:si5;^,  visible*: 5^52!) • 
Correspondingly,  pmod'  is  formed  from  pmod  by  a  sequence  of  visible*  projections, 
unroll’ings,  and  fetch’es. 

—  Soundness:  decs  h  pmod'  :p  sig' . 

—  Comments:  This  judgment  is  useful  when  we  want  to  check,  for  example,  that  a  given 
module  is  really  a  functor,  but  we  do  not  have  a  particular  target  signature  that  we  are 
matching  it  against  (Rule  9.49).  It  also  inserts  automatically  the  fetch’es  of  recursive 
module  variables  and  unroll’ings  of  rds’s  that  the  EL  syntax  leaves  implicit.  I  will  say 
that  a  module  pmod  is  in  “peeled  form”  if  decs  hj^eei  pmod: sig  ^  pmod  :  sig. 

Label  Lookup 

•  T  l^tx  labs  phrase  :  class 

—  Interpretation:  Lookup  the  component  indexed  by  labs  in  the  context  T  and  return  it 
(phrase)  along  with  a  class  describing  it. 

—  Soundness:  T  h  phrase  :  class.  If  phrase  is  a  module,  it  is  a  pmod  and  it  is  guaranteed 
to  be  in  peeled  form,  i.e.,  T  l|,eei  phrase: class  phrase  :  class. 

—  Comments:  The  lookup  algorithm  looks  for  the  first  lab  in  labs.  It  searches  right-to-left 
through  r,  and  looks  inside  the  signatures  of  modules  that  have  open  labels  (ilab*)  using 
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the  signature  lookup  judgment  (below).  Once  it  finds  the  first  lab,  it  uses  the  signature 
lookup  judgment  to  look  for  the  remaining  labs  if  there  are  any. 

•  decs;pmod:sig  Igig  labs  phrase  :  class 

—  Interpretation:  Given  a  module  pmod  of  signature  sig,  lookup  the  component  indexed 
by  labs  in  sig,  and  return  the  resulting  phrase  (and  its  class),  which  will  be  a  projection 
from  pmod. 

—  Soundness:  T  h  phrase  :  class.  If  phrase  is  a  module,  it  is  a  pmod  and  it  is  guaranteed 
to  be  in  peeled  form,  i.e.,  F  l^eei  phrase: class  phrase  :  class. 

—  Comments:  This  judgment  is  defined  in  a  similar  manner  to  the  context  lookup 
judgment — it  searches  for  the  head  of  labs  right-to-left  among  the  specifications  that 
comprise  sig,  and  then  calls  itself  recursively  if  there  are  more  labs. 

Recursive  Module  Elaboration 

•  r  btat  binding (s)  metaldec{s) 

r  iitat  modexp  ^  metasig 

—  Interpretation:  Given  an  EL  binding {s)  or  modexp,  perform  static  elaboration  of  it 
(ignoring  val  bindings,  etc.)  and  return  a  meta-signature  or  meta-declarations  that 
reflect  what  type  information  is  known  in  different  parts  of  the  input. 

—  Soundness:  T  h  metaldec{s)  ok,  T  h  metasig  :  Sig. 

—  Comments:  This  is  the  first  phase  of  recursive  module  elaboration,  and  it  only  succeeds 
if  the  input  is  pure/separable,  i.e.,  has  purity  classifier  P.  See  Section  5.4  for  a  high-level 
explanation.  This  judgment  is  also  used  by  Rule  9.13  in  order  to  determine  whether  a 
module  expression  is  projectible.  Specifically,  if  the  input  modexp  is  projectible,  then  it 
will  not  contain  any  datatype  bindings  or  any  uses  of  sealing,  so  the  output  metasig  will 
have  the  form  of  a  normal  signature  (in  fact,  it  will  be  a  transparent,  static  signature). 

•  T;  metadec;T'  bee  pmod  binding{s)  lbnd{s)  :  tldec{s) 

T;  metadec;T'  bee  pmod  modexp  mod  :  tsig 

—  Interpretation:  The  main  phase  of  recursive  module  elaboration. 

—  Soundness:  Assuming  T  h  metadec  ok  and  h  T,  Pub(metodec),  T'  ok, 

then  T,  Priv(metadec),  T'  h  lbnd{s)  tldec{s)  and  T,  Priv(metadec),  T'  h  mod  :p  tsig. 

—  Comments:  pmod  tells  us  what  part  of  the  recursive  module  body  we  are  currently 
elaborating,  and  the  metadec  in  the  context  allows  us  to  switch  from  public  to  private 
knowledge  of  certain  type  information  when  elaboration  goes  underneath  a  sealed  module 
expression.  Note  that  the  soundness  property  is  rather  weak;  it  only  says  that  the 
output  is  well- formed  assuming  the  full  private  setting  of  the  metadec.  This  is  because 
different  parts  of  the  input  are  typechecked  under  different  settings  of  metadec,  and 
Priv(mefadec)  is  the  least  common  denominator  in  the  subtyping  hierarchy.  For  more 
details,  see  Section  9.3.8. 
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9.3  Elaboration 

9.3.1  A  Few  More  Preliminaries 

•  Given  an  elaboration  context  F,  let  labdoni(r)  be  the  set  of  labels  on  the  entries  in  F,  and 
let  vardom(F)  be  dom(IL(F)). 

•  I  will  sometimes  write  var=phrase  or  lab=phrase  instead  of  lab>var=phrase  when  I  do  not 
care  what  lab  or  var  is,  respectively.  In  either  case,  to  form  a  proper  Ibnd,  one  can  choose 
some  fresh  internal  label  or  variable  to  fill  in  whatever  was  omitted.  Similarly,  I  will  sometimes 
write  var-.class  or  lab'.class  instead  of  lab\>var:class  when  I  do  not  care  what  lab  or  var  is, 
respectively.  In  either  case,  to  form  a  proper  Idee,  one  can  choose  some  fresh  internal  label 
or  variable  to  fill  in  whatever  was  omitted. 

•  I  will  sometimes  extend  an  elaboration  context  F  with  a  metaldec.  This  is  shorthand  for 
extending  F  with  Pub{metaldec). 

•  Given  a  list  of  Ideas,  labdom(Wecs)  is  not  an  entirely  accurate  description  of  the  labels  that 
Ideas  exports,  since  it  does  not  take  into  account  labels  of  components  in  the  signatures  of 
open  modules.  The  function  vislabs( Wees),  defined  here,  computes  more  accurately  the  set 
of  “visible”  labels,  i.e.,  the  labels  that  the  signature  lookup  routine  will  succeed  in  finding  if 
it  looks  for  them  in  the  signature  |Wecs].  This  function  comes  in  handy  in  Rule  9.57. 


vislabs(Wecs) 

vislabs(-) 

vislabs(Wec,  Ideas) 

=  0 

=  vislabs(Wec)  U  vislabs(Wecs) 

vislabs(Wec) 

vislabs{lab:knd) 

=  {lab} 

vislabs(W6:  con) 

=  {lab} 

vislabs(W6:si5) 

=  {lab},  if  lab  is  not  open 

vislabs  {lab*:  pdeesj ) 

=  vislabs  (Wees) 

vislahs{lab*:p{mvar).sig) 

=  vislabs  (WWrsig) 

•  Following  HS,  I  handle  shadowing  of  EL  identifiers  by  means  of  an  operation  of  syntaatia 
aonaatenation  with  renaming.  Written  {lbnds++lbnds')  :  (Wecs++Wecs'),  this  operation 
takes  two  lists  of  Ibnds  (and  corresponding  Ideas)  and  joins  them  together,  taking  care  to 
correct  for  duplicate  labels  by  relabeling  any  shadowed  Ibnds /Ideas  of  the  first  list  with  fresh 
internal  labels.  Defined  as  follows,  it  comes  in  handy  in  Rule  9.30; 

(•  ++lbnds')  :  (•  ++Wecs')  '=  Ibnds'  :  Ideas' 

{lab>bnd,  lbnds++lbnds')  :  {lab\>dea,  ldeas-\-+ldeas') 

{lab>bnd,  Ibnds"  :  lab\>dea.  Ideas"  if  lab  0  lab dom( Wees'') 

ilab>bnd,  Ibnds"  :  ilab>dea.  Ideas"  otherwise,  where  ilab  0  labdom(Wecs") 

and  ilab  is  open  iff  lab  is 

where  Ibnds"  :  Ideas"  =  {Ibnds ++ Ibnds')  :  (Wecs++Wecs') 

•  The  elaborator  assumes  the  presence  of  a  structure  basis -.{Ideas  basis}  serving  as  the  initial  basis 
for  the  internal  language.  Ideas  basis  must  contain  at  least  the  following  fields,  which  define 
three  exceptions,  as  well  as  equality  functions  for  some  fixed  set  of  base  types  aon: 

Bind*  :|tag;UnitTag, BindiTagged], 

Mat ch*:|tag; Unit  Tag,  MatchiTagged], 
fail*  :|tag;UnitTag,  faikTagged] 
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•  In  a  number  of  rules,  certain  premises  have  the  form  metavariable  =  something ,  whereas 
others  have  the  form  metavariable  :=  something .  I  take  “=”  and  both  to  mean  syntactic 
equality.  However,  in  order  to  read  the  rules  algorithmically,  one  should  interpret  the  former 
as  “has  the  form” ,  and  the  latter  as  “is  defined  to  be” . 

•  In  a  number  of  rules,  I  write  a  wildcard  _  in  the  output  of  a  premise  when  it  is  important 
that  the  premise  succeed,  but  it  is  irrelevant  what  the  output  is. 

•  Optional  elements  in  rules  are  enclosed  in  angle  brackets.  For  each  rule,  either  all  or  none  of 
the  elements  in  angle  brackets  must  be  present.  In  some  cases,  the  optional  element  notation 
is  insufficient.  Therefore,  we  have  the  additional  notation 

elementi 
or 

element2 

which  means  that  either  element i  or  element2  must  be  present.  If  there  are  multiple  such 
choices  in  a  single  rule,  this  means  that  either  the  first  element  should  be  chosen  in  all  cases, 
or  the  second  element  should  be  chosen  in  all  cases.  An  extension  of  this  notation  gives  the 
choices  subscripts.  Then  all  choices  with  the  same  subscript  must  agree  (all  first  element  or 
all  second  element)  but  two  choices  with  different  subscripts  are  completely  independent. 

•  To  make  things  more  concise,  I  often  view  the  monomorphic  instance  of  an  expression  as  a 
special  case  of  the  polymorphic  instance.  Except  when  otherwise  noted,  the  kind  T”— >T,  the 
type  \/{cvarp:kndp).con  and  the  term  exp[conp\  may  be  considered  shorthand  for  T,  con  and 
exp,  respectively,  in  the  monomorphic  instance  when  n  =  0. 

•  There  are  some  kinds  that  may  also  be  viewed  as  signatures,  e.g.,  knd  =  |1:T,  •  •  •  ,n:T].  It 
should  be  clear  from  context  which  syntactic  class  is  intended.  For  instance,  if  knd  is  used  to 
classify  a  cvar,  then  it  is  a  kind;  but  if  knd  is  used  to  classify  a  mvar,  then  it  is  a  signature. 

As  shown  in  Figure  9.3,  the  elaborator  makes  use  of  a  number  of  derived  forms  of  IL  objects, 
most  of  which  are  self-explanatory.  A  few  points  of  note: 

•  A  number  of  the  derived  form  definitions  invent  new  variables  on  the  right-hand  side.  These 
variables  are  always  assumed  to  be  fresh  in  the  sense  that  they  do  not  clash  with  the  free 
variables  of  the  expression. 

•  I  will  sometimes  write  A-expressions  without  the  result  type  when  it  can  be  inferred  from 
context. 

•  plet  is  a  projectible  encoding  of  module-level  let,  assuming  the  submodules  are  projectible. 
elet  stands  for  “existential”  let,  and  is  used  to  introduce  modules  of  “existential”  signature. 
See  the  translation  of  module  expressions  for  examples  of  how  these  derived  forms  are  used. 

•  catch™”  exp  with  exp'  attempts  to  evaluate  exp  (which  has  type  con).  If  an  exception  is  raised, 
catch  checks  whether  it  is  the  “fail”  exception.  If  so,  exp'  is  evaluated;  if  not,  the  exception 
is  reraised. 

•  pproj^^^  *  evaluates  exp  to  a  value  of  the  given  sum  type,  and  then 

checks  whether  it  is  tagged  with  labk-  If  so,  it  projects  out  the  underlying  value  (of  type 
conk)',  if  not,  the  exception  exp'  is  raised. 
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Unit 

def 

{} 

Bool 

def 

S{l:Unit,  2:Unit} 

false 

def 

{} 

true 

def 

{} 

if  expQ  then  exp2  else  expi 

def 

case  expQ  of  {i  i— >  Xevar:\}n\t.exp end 

X{evar:con):con' .exp 

def 

fixi  evar' {evar:con):con' =exp  end 

knd^ 

def 

{l:knd,  •  •  • ,  n:knd} 

kndi  X  •  •  •  X  kndn 

def 

{l:kndi,  •  •  • ,  n:kndn} 

(coni,  ■■■ ,  conn) 

def 

{l=coni,  •  •  • ,  n=conn} 

coni  X  •  •  •  X  conn 

def 

{l:coni,  •  •  •  ,n:conn} 

{expi,  •  •  • ,  expn) 

def 

{T=expi,  -  ■  ■  ,n=expn} 

n(c?;ari,  •  •  • ,  cvarn).knd 

def 

Il{cvar:T'^)  .knd[cvar  .i  / 

X{cvari,  •  •  • ,  cvarn).con 

def 

X{cvar:T"’).con[cvar.i/ cvavi]'^^.^ 

V(cTOri,  •  •  • ,  cvarn).con 

def 

y{cvar:T^).con[cvar.i/ cvaxi]'^^.^ 

A{cvari,  •  •  • ,  cvarn).exp 

def 

A{cvar:T^).exp[cvar.i/ cvari]^^i 

let  cvar=con  in  {mod  :  sig) 

def 

let  mvar=[l=con]  in  {mod[mvaN .1/ cvar] :  sig) 

{mod. lab  :  con) 

def 

let  mvar=mod  in  {mvar.lab  :  con),  when  mod  ^  pmod 

{mod. lab  :  sig) 

def 

let  mvar=mod  in  {mvar.lab  :  sig),  when  mod  ^  pmod 

plet  mvar=pmodi  in  pmod2 

def 

\l\>mvar=pmodi,2=pmod<^.2 

elet  mvar=modi  in  mod2 

def 

[hiddeno mxar= modi,  visible* =mod‘^ 

3{mvar-.sigi).sig2 

def 

|hiddeni>  mvar :  ^ ,  visible  * ;  sig  2 1 

fail  con 

def 

raise“"  6osis. fail*. fail 

catch“"  exp  with  exp’ 

def 

handle  exp  with  Aez;ar:Tagged. 
iftagof  evar  is  6asis. fail*. tag 
then  Aemr:Unit.exp'  else  raise“"  evar 

.S|(Za6ii-^coni)l‘_l  1  / 

PProJzaL  ’  {exp,  exp  ) 

def 

case  exp  of 

labi  ^  Aemr:coni.raise“”''  exp',  •  •  • , 
labk  1-^  Xevar-.conk-evar ,  ■  ■  ■ , 
labn  1-^  Aecar:con„. raise“”'=  exp' end 

Figure  9.3:  Derived  Forms 


•  Although  I  have  not  written  their  definitions  down  here,  I  assume  that  less  restrictive  versions 
of  most  IL  term  constructs  have  been  defined  (in  terms  of  let)  that  permit  subterms  to  be 
arbitrary  terms,  not  just  values,  and  that  evaluate  those  subterms  in  left-to-right  order.  For 
example,  I  treat  expi  exp2  as  shorthand  for  let  evari=expi  in  let  evar2=exp2  in  evari  evar2. 
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9.3.2  Main  Translation  Rules 
Type  Expressions 


T  \-  ty  con  :  T 


r  h  int  Int  :  T 


(9.7) 


Rule  9.7:  There  are  analogous  rules  for  the  other  base  types  (int,  bool,  unit,  string,  etc.), 
and  the  base  type  constructors  (ref). 


r  h  exn  Tagged  :  T 

(9.8) 

r  Vtx  tyvar  ^  eon  :  T 
r  h  tyvar  con  :  T 

(9.9) 

Rule  9.9:  As  ML  does  not  support  higher-kinded  polymorphism  at  the  core  language  level,  type 
variables  all  have  kind  T. 


Vi  G  l..n  :  T  h  tVj  coui  :  T  ^  ^ 

-  '  - ^ -  (9.10) 

r  h  {reclabi :  tyi ,  •  ■  ■  ,  reclabn :  ty,^}  {rec/a6i:coni,  •  •  • ,  reclabn-coun}  ■  T 


T  \-  ty  con  :  T  T  \-  ty'  con'  :  T 
T  ty  ->  ty'  con  — >  con'  :  T 


r  Vtx  longconid  ^  con  :  T 

Vi  G  l..n  :  T  \-  ty^'^  coni  :  T 
r  h  {tyi,  ■  ■  ■  ,tyn^  longconid  ^  con  {coni,  ■  ■  ■ ,  conn)  ■  T 


(9.11) 


(9.12) 


r  iitat  modexp  tstatsig 
r,  mvar:tstatsig;  mvar:tstatsig  fiig  conid  con'  : 
con  :=  con'[CBn{Vs\.{tstatsig)) / mvaH] 

Vi  G  l..n  :  T  h  ij/j  coni  :  T 
modexp  is  not  of  the  form  longmodid 
r  h  (ty^ ,  ■  ■  ■  ,  ty^)  modexp. conid  con{coni,  •  •  • ,  conn)  ■  T 

Rule  9.13:  Projecting  a  type  from  a  module.  We  must  check  that  modexp  is  projectible. 
To  do  this,  we  perform  static  elaboration  (aka  the  first  phase  of  recursive  module  elaboration) 
and  check  that  the  static  signature  of  modexp  is  in  fact  transparent.  (Recall  that  transparency 
and  projectibility  amount  to  the  same  thing.)  We  can  then  project  out  the  eonid  component  of 
Can{fst{tstatsig)). 

The  reason  we  perform  static  elaboration  on  modexp  instead  of  ordinary  elaboration  is  that 
the  dynamic  components  of  modexp  are  irrelevant  as  far  as  projection  of  its  type  components  is 
concerned.  Just  as  Fst{mod)  may  be  well-formed  even  if  mod  is  not,  so  modexp  .eonid  may  be 
well- formed  even  if  modexp  is  not. 
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Term  Expressions 


r  h  scon  ^  scon  :  type(scon) 


r  h  expr  ^  exp  :  con 
(9.14) 


Rule  9.14:  We  assume  a  meta-level  function  type  which  gives  the  IL  type  of  each  constant. 


r  i^tx  longexpid  ^  exp  :  'i{cvarp-.kndp).con 
r  h  conp  :  kndp 

r  h  longexpid  exp[conp]  :  con[eonp/ cvavp] 


(9.15) 


Rule  9.15;  Potentially  polymorphic  variables.  This  is  an  instance  of  nondeterminism,  where  we 
must  guess  the  conp  with  which  to  instantiate  the  type  arguments  of  exp,  if  there  are  any. 


r  h  modexp  ^  mod  sig 

r,  mvar:sig;  mvav.sig  liig  expid  exp  :  \/{cvarp:kndp).con' 
r,  mvar-.sig,  cvacp-.kndp  h  con'  =  con  :  T 
r,  cvavp.kndp  h  con  :  T  T  h  conp  ;  kndp 
modexp  is  not  of  the  form  longmodid 

r  h  modexp. expid  let  mvar=mod  in  {exp[conp] :  con[conp/ cvavp])  :  con[conp/ cvavp] 


(9.16) 


Rule  9.16;  modexp.  expid  is  elaborated  as  if  it  were  let  module  modid  =  modexp  in  modid.  expid  end. 
See  the  elaboration  of  let  bindings  (Rule  9.18  below). 


Vi  G  l..n  :  T  h  expr^  exp^  :  coni 
r  h  {reclabi  =  expri ,  ■  ■  ■  ,  reclabn  =  expr^} 

{reclabi=expi,  ■  ■  ■ ,  reclabn=expj^}  :  {reclabp.coni,  ■  ■  ■ ,  reclabn'- conn} 


(9.17) 


r  h  bindings  ^  Ibnds  :  Idecs 
T,ilab*>mvar:lldecs}  h  expr exp  :  con' 
r,  mvar:\ldecs\  h  con'  =  con  :  T  T  h  con  :  T 
r  h  let  bindings  in  expr  end'^^  let  mvar=[lbnds]  in  {exp :  con)  :  con 


(9.18) 


Rule  9.18:  The  “open  label”  convention  is  used  here  to  make  the  local  bindings  accessible  while 
translating  expr.  The  elaborator  verifies  that  the  translated  expression  can  be  given  a  a  type, 
which  must  not  depend  on  any  abstract  types  defined  by  bindings.  As  a  practical  matter,  this  can 
always  be  achieved  by  computing  the  normal  form  of  con'  (by  Stone  and  Harper’s  normalization 
algorithm  [75])  and  then  checking  to  make  sure  that  mvar^  is  not  free  in  it. 


r  h  expr  exp  :  con"  — >  con 
r  h  expr'  ^  exp'  :  con' 
r  h  con'  =  con"  :  T 
Rule  9.20  does  not  apply. 

T  h  expr  expr'  ^  exp  exp'  ;  con 

Rule  9.19:  General  function  application,  where  exp  is  not  a  datatype  constructor. 


(9.19) 
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r  i^tx  longexpid  ^  pmod.labi  :  'i {cvarp-.kndp) .corii  con 

r  h  pmod.conid-m  :  \/{cvarp\kndp).con^'^'^  con 
con™™  =  S{Za6i:coni, . . . ,  labn'conn} 
r  h  expP  'xo-  exp'  :  con' 

r  h  conp  :  kndp  T  h  con'  =  coni[conp/ cvacp]  :  T 
r  h  longexpid  expr'  ^  pmod.conid_m[conp]{{\n]^^^  [coup/cvarp]  .  QorL[conpl cvar^ 

Rule  9.20;  Application  of  a  (potentially  polymorphic)  datatype  constructor.  The  rule 
complicated  only  because  we  make  the  optimization  of  inlining  the  constructor  application  as  an 
injection  into  the  appropriate  sum  type,  followed  by  a  call  to  the  datatype’s  in  coercion. 

r  h  expr  exp  ;  con 
T  \-  ty  con'  :  T  T  h  con  =  con'  :  T 

- -  (9-21) 

r  h  expr  :  ty  exp  :  con 

Rule  9.21:  Type  constraints  on  expressions  are  verified,  but  do  not  appear  in  the  translation. 


(9.20) 
is  a  bit 


r  h  expr  ^  exp  :  con  T  h  match  ^  val  :  Tagged  ^  con'  T  h  con  =  con'  ;  T 

(  J 

r  h  expr  handle  match 

handle  exp  with  A(ecar:Tagged):con. (catch val  enar  with  raise evar)  :  con 


Rule  9.22;  The  handling  expression  val  evar  will  fail  if  the  handler  pattern  does  not  match  the 
exception  caught  by  the  IL  handle,  in  which  case  we  re-raise  the  exception. 


r  h  expr  ^  exp  :  Tagged  T  h  con  :  T 
r  h  raise  expr  raise™”  exp  :  con 

Rule  9.23:  raise  expressions  can  be  given  any  (valid)  type. 


(9.23) 


r  h  match  ^  val  :  coni  con^ 

r  h  fn  match  ^ 

A(enor:coni):con2.(catch™"’^  val  enor  with  raise™”^  6asis. Match*. Match)  : 
coni  — >  con2 


(9.24) 


Rule  9.24;  The  application  exp  var  will  fail  if  the  match  fails;  we  turn  the  failure  into  a  match 
exception. 


r  h  modexp  mod  sig  T  i^tx  longconid  ^  vpmod.lab  :  T 
r  h  vpmod.lab -pack  :p  sig' vpmod.lab} 
r,  mvav.sig  liub  rnvar  :  sig  <  sig'  pmod'  :  _ 

r  h  pack  modexp  as  longconid 

let  mvar=mod  in  (vpmod .lab -pack'^^' {pmod') .it :  vpmod.lab)  :  vpmod.lab 


(9.25) 


Rule  9.25;  The  package  type  is  required  to  be  a  longconid  so  that  the  “pack”  functor  is  easy  to 
locate. 
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Matches 


r  h  match  ^  val  :  con 


r  h  con'  :  T 

r,  evar:con'  h  pat  evar  :  con'  else  6asis. fail*. fail Ibnds  :  Idecs 
T ,Uah*>mvar\\ldecs\  h  expr  ^  exp  :  con 
r  h  pat  =>  expr  \{evar-.con')\con.\e\.  mvar=[lhnds\  in  {exp  :  con)  :  con'  — >  con 


(9.26) 


Rule  9.26:  The  type  con  is  well-formed  in  T  because  the  Idecs  only  contain  term  declarations. 


r  h  mrule  val  :  coni  con2 

r  h  match  ^  val'  ;  con'i  con'2 

r  h  coni  ^  con2  =  con'^  con'2  ■ 

r  h  mrule  I  match  ^  A(emr;coni):con2.catch“"^  val  ecar  with  val'  evar  :  coni  con2 


(9.27) 


Bindings 


r  h  bindings  ^  Ibnds  Idecs 


T  h  •  •  :p  • 


(9.28) 


r  h  sigexp  sig  :  Sig  T,  sigid=sig  h  bindings  Ibnds  Idecs 
r  h  signature  sigid  =  sigexp  (;)  bindings  Ibnds  Idecs 


(9.29) 


Rule  9.29;  signature  bindings  do  not  produce  any  actual  IL  bindings  or  declarations;  they  just 
provide  shorthand  for  signature  expressions  during  elaboration. 


r  h  binding  ^  Ibndsi  Idecsi 
r,  Idecsi  h  bindings  lbnds2  '.k2  ldecs2 
r  h  binding  {;)  bindings^  Ibnds i++lbnds2  ■kiUk2  ldecsi++ldecs2 


(9.30) 


Rule  9.30;  The  syntactic-concatenation-with-renaming  operation  is  used  here  to  relabel  any 
shadowed  bindings  from  Ibnds  i. 


r  h  binding  ^  Ibnds  Idecs 


r  h  expr  ^  exp  :  con 

r,  evar:con  h  pat  evar  :  eon  else  6asis. Bind*. Bind Ibnds  :  Idecs 
r  h  val  pat  =  expr  ilab\>evar=exp,  Ibnds  :?  ilab> evar: con,  Idecs 


(9.31) 


Rule  9.31:  Monomorphic  val  bindings.  If  the  pattern  match  fails,  we  catch  the  fail  exception  and 
reraise  a  bind  exception.  We  separate  monomorphic  val  bindings  from  polymorphic  val  bindings 
because  polymorphic  bindings  impose  a  value  restriction  on  exp  while  monomorphic  bindings  do 
not. 
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kndp  :=  {tyvari.T,  •  •  • ,  tyvar^:T,  1:T,  •  •  • ,  /c:T] 
r,  ilab*\>mvarp\kndp  h  expr  vexp  :  con 
r'  :=  r,  Uab*>mvarp:kndp,  evarX {mvarp-.kndp) .con 
r'  h  pat  evar[mvar’^  :  con  else  6asis. Bind*. Bind 

labi=vexpi,  ■  ■  ■ ,  labn=vexpn  :  labi'.coni,  •  •  • ,  labn'conn 
Mi  G  l..n  : 

Ibndi  :=  labi=A{mvarp:kndp).vexp^ 

Ideci  :=  labiN {navarp-.kndp) .coni 
r  h  val  (tyvari ,  •  •  •  ,  tyvar^)  pat  =  expr 

ilab>evar=A{mvarp:kndp).vexp,  Ibndi,  •  •  • ,  Ibndn  :p 
ilab>evar:M{mvarp:kndp) .con ,  Ideci,  •  •  • ,  Idecn 


(9.32) 


Rule  9.32;  Polymorphic  val  bindings.  Like  HS,  I  assume  that  a  val  declaration  is  explicitly 
annotated  with  the  type  variables  scoped  in  that  declaration.  Type  inference  may  introduce  k 
additional  type  variables  that  are  not  mentioned  in  the  source  (as  in  val  f  =  fn  x  =>  x).  The 
translation  of  expr  is  required  to  be  valuable,  so  that  the  type  abstraction  in  the  output  of  the 
rule  is  well-formed  and  does  not  suspend  any  computational  effects.  I  require  all  the  pattern¬ 
matching  bindings  to  be  valuable  as  well;  this  means  effectively  that  pat  must  be  irrefutable  and 
not  contain  any  ref  patterns.  (This  requirement  marks  a  departure  from  HS,  in  which  some  of  the 
pattern  bindings  are  allowed  to  be  non-valuable  and  are  consequently  not  generalized.  I  believe  my 
semantics  is  easier  to  understand,  and  it  conforms  more  closely  to  what  is  implemented  in  TILT.) 


kndp  :=  {tyvaci.T,  •  •  • ,  tyvar^:T,  1:T,  •  •  • ,  /c:T] 

r'  :=  r,  ilab*>mvarp:kndp,  expidi^evar'i'.coni  eon'i,  •  •  • ,  expidji>evarn.eonn  — ^  eon'^ 

Mi  G  l..n  ;  T'  h  matchi  \{evari-.coni)\con[.expi  :  coni—>  eon[ 
valk  ■=  fixfc  {evar[{evari:coni):con~expi)^^iend 
r  h  fun  {tyvari  >  •  •  •  >  tyvar^)  expidi  =  fn  matehi  and  •  •  •  and  expid^^  =  fn  matchn 
expidi=A{mvarp:kndp) .vail,  ■  ■  ■ ,  expid„^=A{mvarp: kndp). vain  :p 
expidi'A/ {mvarp-.kndp) .coni  con'i,  ■  ■  ■ ,  expidn'N{mvarp-.kndp).conn  — >  con'n 

Rule  9.33;  My  syntax  for  fun  bindings  is  slightly  different  from  SML’s.  It  would  not  be  difficult 
to  support  SML-style  clausal  function  dehnitions  by  desugaring  them  into  the  present  syntax. 


Mi  G  l..n  ;  T  htx  longmodidi  ^  pmodi  :  tsigi 
r  h  open  longmodidi  ' ' '  longmodidn 

ilabi*=pmodi,  •  •  • ,  ilabn*=pmodn  ;p  ilabi*: tsigi, ' ' '  >  ilabn*'.tsign 

Rule  9.34;  Makes  the  components  of  the  opened  modules  visible  in  the  current  namespace  by 
binding  with  open  labels.  The  signatures  of  the  modules  are  specified  as  tsig's  simply  to  emphasize 
that  the  signatures  of  projectible  modules  are  transparent. 


T  \-  ty  con  ;  T 

- - -  (9.35) 

r  h  exception  expid  of  ty  ^ 

iZa6*=[tag>etar=new_tag[con],  ea;pid=A(emr';con);Tagged.tag(emr,  evar')]  ;p 
iZa6*;|tagi>emr;con  Tag,  expid:con  Tagged] 
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r  h  exception  expid 

iZa6*=[tag>e?;ar=new_tag[Unit],  expid=tag{evar ,  {})]  :p 
iZa6*:|tagi>e?;ar:UnitTag,  expi(i:Tagged] 

r  ^^tx  long  expid  pmod.lab  :  con 
r  h  pmod.tag  :  con' 
r  h  exception  expid  =  longexpid 

ilah* =[iag=pmod .lag,  expid=pmod .lab]  :?  ilab* :ltag: con' ,  expid:con} 


(9.36) 


(9.37) 


Rule  9.37;  Structures  containing  a  “tag”  component  are  created  by  EL  exception  declarations 
only. 


r  h  bindings  I  Ibndsi  Idecsi 

T ,  ilab*>mvar:lldecsi}  h  bindings2  lbnds2  ■k2  ldecs2 

r  h  local  bindings^  in  bindings2  end'^ 

ilab>mvar=[lbndsi],  lbnds2  ■kiUk2  ilab>mvar:lldecsi},  ldecs2 

Rule  9.38:  This  rule  exemplifies  HS’s  approach  to  the  avoidance  problem,  which  I  have  followed. 
Bindings  are  exported  for  all  of  the  declarations,  so  it  is  perfectly  OK  for  the  public  Ideas  2  to  refer 
to  the  private  Idecsi  (since  the  Idecsi  do  not  go  out  of  scope).  The  Idecsi  are  guaranteed  to  be 
inaccessible  from  the  EL,  however,  because  they  are  segregated  into  a  substructure  with  an  internal 
label  (that  is  not  open). 


T,  tyvari>cvari:T,  •  •  • ,  tyvar .^>cvarn'.T  \-  ty  con  :  T 
T  h  type  (tyvavi ,  ■  ■  ■  ,  tyvar.^)  conid  =  ty  ^ 

conid=X{cvari,  •  •  • ,  cvarn).con  :p  comd:n(c?;ari,  •  •  • ,  cvarn).5{con) 


(9.39) 


r  l^tx  long  conid  ^  pmod.lab  :  tknd 
T  h  pmod  :p  llab>cvar:tknd,  lab -uwconia-,  lab -oal:  con  out-,  ldecs\ 
Idecs  =  labi>deci,  ■  ■  ■ ,  labn>decn 


T  h  datatype  conid  =  datatype  longconid 

.m=pmod.lab 


(9.40) 


ilab*= 


-in, 


conid>cvar=pmod .lab ,  conid. 
conid -onl= pmod. lab -ont,  labi=pmod.labi,  •  •  • ,  labn=pmod.labr 


ilab*:\conid\>cvar:tknd,  conid -m.:con\a_,  conid -OvX:  con  out,  ldecs\ 


Rule  9.40:  Copying  a  datatype  essentially  involves  copying  the  whole  module  that  defines  the 
datatype,  its  in  and  out  coercions,  and  its  data  constructors.  Unfortunately,  we  cannot  just  copy 
the  whole  module  all  at  once  because  the  name  of  the  new  type  affects  the  labels  assigned  to  the 
type  component  and  the  in  and  out  coercions. 


r  h  datbinds  ^  sig 


TK 


sig 


mod 


T  h  datatype  datbinds  ^  ilab*={mod  :>p  sig)  :  ilab*:sig 


(9.41) 


Rule  9.41;  Eor  datatype  bindings,  we  compute  the  canonical  implementation  of  the  correspond¬ 
ing  datatype  spec. 


212 


CHAPTER  9.  EVOLVING  THE  ML  EXTERNAL  LANGUAGE 


mod  := 


r  h  sigexp  ^  sig  :  Sig 
conid>cvar= sig  ^ , 

coni(i_pack=AP^''(m?;ar:sig):|it:cmr].[it=  pack  mvar  as  sig], 
coni(i_unpack=AP^'’(mmr:[it:c?;ar]);sig.unpack  mvar.ii  as  sig 
\  conidt>cvar-.T ,  1 


sig' 


coni(i_pack:sig-^|it;  c?;ar] , 
coni(i_  unpack:  |it :  ct;ar]  sig 


r  h  packtype  conid  =  sigexp  ilab*={mod  :>p  sig')  ilab*:sig' 


(9.42) 


Rule  9.42:  It  is  necessary  that  the  “unpack”  functor  be  partial,  since  unpacking  is  an  im¬ 
pure/inseparable  operation.  It  does  not  matter  whether  the  “pack”  functor  is  total  or  partial,  since 
it  is  only  ever  applied  by  Rule  9.25. 


r  h  modexp  ^  mod  sig 

r  h  module  modid  =  modexp  modid=mod  modid:sig 


(9.43) 


Module  Expressions 


r  h  modexp  ^  mod  sig 


Note:  The  translation  rule  for  recursive  modules  is  presented  in  Section  9.3.8. 


r  i^tx  longmodid  ^  pmod  :  tsig 
r  h  longmodid  ^  pmod  :p  tsig 

(9.44) 

r  h  bindings  Ibnds  Ideas 

(9.45) 

r  h  struct  bindings  end^  [Ihnds]  |Wecs] 

r  h  modexp  ^  mod  sig 
r,  mvar: sig;  mvar: sig  liig  modid  pmod  :  tsig 
modexp  is  not  of  the  form  longmodid 
r  h  modexp  .  modid  elet  mvar=mod  In  pmod  3 (m?;ar: sig). tsig 


(9.46) 


Rule  9.46:  modexp  .modid  is  elaborated  as  if  it  were  let  module  modid'  =  modexp  in  modid'  .modid  end. 
See  the  elaboration  of  module- level  let  bindings  (Rule  9.50  below). 


r  h  sigexp  ^  sig  :  Sig 
r,  modid>mvar:sig  h  modexp  mod  :?  sig' 

r  h  functor  (modid  :  sigexp)  ->  modexp  ^ 
{mvar: sig). mod  :p  (mtor: sig). sig' 

r  h  sigexp  ^  sig  :  Sig 

r,  modid> mvar: sig  h  modexp  mod  sig' 
r  h  functor  (modid  :  sigexp)  -»  modexp 

{mvar:sig):sig' .mod  :p  {mvar:sig) .sig' 


(9.47) 


(9.48) 
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r  h  modexpi  modi  Ti  sigi 
r  h  modexp2  mod2  '■k2  sig2 
r'  :=  r,  mvari'.sigi.,  mvar2'.sig2 
r'  f^eei  mvari'.sigi  pmod  :  IV {mvar-.sig').sig" 
iiub  mvar2  :  sig2  ^  sig'  pmod'  :  _ 


J  P  if  Ki  =  ^2  =  P  and  r  =  tot 
[  I  otherwise 


r  h  modexpi(modexp2') 

elet  mvari=modi  in  elet  mvar2=mod2  in  pmod'^ {pmod' ) 
3  ( mvari :  sig  i).3{  mvar2 :  5*52 )  •  [pmod'  /  mvar] 


(9.49) 


Rule  9.49:  Note  the  use  of  peeling  to  uncover  the  underlying  functor  signature  of  modi. 


r  h  bindings  ^  Ibnds  Ideas 
r,  ilab*>mvar:lldecs}  h  modexp  ^  mod  sig 

r  h  let  bindings  in  modexp  end 

elet  mvar  =[lbnds]\n  mod  ;kiUk2  3{mvar:lldees}).sig 

r  h  modexp  ^  mod  sig  F  h  sigexp  ^  tsig  :  Sig 
r,  mvar: sig  liub  mvar  :  sig  ^  tsig  pmod  :  _ 
r  h  modexp  seal  sigexp  ^  purify(let  mvar=mod  in  (pmod  :  tsig))  :p  tsig 


(9.50) 


(9.51) 


Rule  9.51:  Regardless  of  what  kind  of  sealing  is  requested,  if  the  sealing  signature  is  transparent, 
then  we  take  this  chance  to  observe  that  the  sealed  module  is  in  fact  pure/separable. 


Rule  9.51  does  not  apply. 

r  h  modexp  ^  mod  Ik  sig  F  h  sigexp  sig'  :  Sig 
F,  mvar: sig  fiub  mvar  :  sig  ^  sig'  pmod  :  tsig 
F  h  modexp  :  sigexp  elet  mvar=mod  \npmod  3{mvar: sig). tsig 


(9.52) 


Rule  9.52:  As  in  SML,  ascribing  a  signature  to  a  structure  using  hides  components  (this 
hiding  being  accomplished  via  an  explicit  coercion),  but  allows  the  identity  of  the  remaining  type 
components  to  leak  through  in  the  transparent  tsig. 


Rule  9.51  does  not  apply. 

F  h  modexp  ^  mod  sig  F  h  sigexp  sig'  :  Sig 

F,  mvar:sig  fiub  mvar  :  sig  ^  sig'  pmod  :  _ 

F  l-  modexp  :  >  sigexp  ^ 

let  mvar=mod  in  {{pmod  :  >p  sig') :  sig')  sig' 

Rule  9.51  does  not  apply. 

F  l-  modexp  ^  mod  sig  F  h  sigexp  sig'  :  Sig 

F,  mvar:sig  fiub  mvar  :  sig  <  sig'  pmod  :  _ 

F  f-  modexp  : »  sigexp  ^ 

let  mvar=mod  in  {{pmod  :  >i  sig') :  sig')  :i  sig' 


(9.53) 


(9.54) 
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Rules  9.53  and  9.54:  Opaque  sealing  does  not  require  the  use  of  an  existential  signature;  we  can 
just  use  a  normal  IL  module-level  let,  as  the  result  is  sealed  with  a  signature  that  is  well-formed 
in  r.  The  only  difference  between  basic  and  impure  sealing  is  which  IL  sealing  construct  they 
translate  into. 


r  h  expr  exp  :  con  T  i^tx  longconid  ^  vpmod.lab  :  T 
r  h  con  =  vpmod.lab  :  T  T  h  vpmod.lab -unpack  :p  |it:con]-^sig 
r  h  unpack  expr  as  longconid  vpmod.lab -unpack'^^'^ {[\i= exp])  :i  sig 


(9.55) 


Specifications 


r  h  specs  ^  Idecs 
r  litat  specs  ^  statldecs 


Normal  and  static  elaboration  rules  for  specifications  and  signature  expressions  are  often  very 
similar.  I  will  write  T  h^stat)  spec{s)  ^  Ideas  and  T  h^stat)  sig  exp sig  :  Sig  in  certain  rules  to 
denote  that  the  rule  can  be  used  to  derive  either  judgment  by  replacing  all  instances  of  with 

h  or  all  instances  of  H^stat)  with  i^tat  • 


r  b^stat)  • 


r  b^gtat)  spec  Idecsi  T,  Idecsi  b^stat)  specs  ldecs2 
vislabs(/decsi)  n  vislabs(/decs2)  =  0 
r  b^stat)  spec  specs  Idecsi,  ldecs2 


(9.56) 


(9.57) 


Rule  9.57;  All  that  is  necessary  for  the  output  Ideas  to  be  well-formed  is  that  labdom(/decsi) 
and  labdom(/decs2)  be  disjoint.  This  condition  would  not,  however,  prevent  one  from  writing  a 
spec  containing,  say,  two  datatype  specifications  of  the  same  type,  due  to  the  use  of  open  labels 
in  specs.  We  therefore  require  additionally  that  the  visible  labels  exported  by  each  spec  be  disjoint 
from  the  visible  labels  exported  by  all  the  other  specs. 


r  b  spec  ^  Ideas 
r  l^tat  spec  ^  statldecs 

r,  tyvari>cvari:T,  •  •  • ,  tyvarj^>cvarn.T  ty  con  :  T 
T  b  val  (tyvari,  •  •  • ,  tyvar^)  expid  :  ty  ^  expid:\/{cvari,  •  •  • ,  cvarn).con 

Rule  9.58;  Specification  of  a  (potentially  polymorphic)  value.  As  with  polymorphic  value 
bindings,  we  assume  that  the  free  type  variables  tyvar^  in  ty  are  bound  explicitly. 


spec  is  a  val  specification, 
r  litat  spec  ■ 

Rule  9.59:  Static  elaboration  ignores  val  specs. 

T  \-  ty  con  :  T 


(9.59) 


r  b  exception  expid  of  ty  ^  expfd:|tag:con  Tag,  expid: con  ^  Tagged] 


(9.60) 
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r  h  exception  expid  expid:|tag;UnitTag,  expid: Tagged] 

spec  is  of  the  form  exception  expid  or  exception  expid  of  ty. 
r  iitat  spec  expid:lj 

r  h^stat)  type  (tyvari ,  ■  ■  ■  ,  tyvar^)  expid  expid:T^^T 


(9.61) 

(9.62) 

(9.63) 


r,  tyvari>cvari:T,  •  •  • ,  tyvarj^>cvarn.T  \-  ty  con  :  T 
r  h^stat)  type  (tyvari ,  ■  ■  ■  ,  tyvar^)  expid  =  ty  ^  expid:Il{cvari,  •  •  • ,  cvarn).S{con) 


r  f^tx  longconid  ^  pmod.lah  :  tknd 
r  h  pmod  ;p  llab>cvar:tknd,  lab_in:conin,  lab-out:conout,  Idecs} 
r  h  datatype  conid  =  datatype  longconid 

ilab* :\conid\>cvar:tknd .,  conid -\mcon\a,  comd_out:conout,  ldecs\ 

r  f^tx  longconid  ^  con  :  tknd 

r  fitat  datatype  conid  =  datatype  longconid  'x->  Hah* ■.\conid-.tknd\ 

r  h  datbinds  sig 
r  h  datatype  datbinds  ilab*:sig 

r  h  datbinds  sig 

r  fitat  datatype  datbinds  ilab* :Stat{sig) 


r  h  sigexp  ^  sig  :  Sig 


sig  := 


conid>cvar-.T , 


conid_pack:sip-^|it;c?;ar] 


conid_  unpack:  |it :  cvar^  sig 


r  h  packtype  conid  =  sigexp  ^  ilab* -.sig' 


sig'  :=  |comd:T,  conid_pack:|-],  corad_unpack:|-]] 
r  iitat  packtype  conid  =  sigexp  ^  ilab*:sig' 

_ r  k(gtat)  sigexp  ^  sig  :  Sig _ 

r  h^stat)  module  modid  :  sigexp  'xa-  modid:sig 
r  k(gtat)  sigexp  ^  sig  :  Sig 
r  h^gtat)  include  sigexp ilab*:sig 


(9.64) 

(9.65) 

(9.66) 

(9.67) 

(9.68) 


(9.69) 

(9.70) 

(9.71) 

(9.72) 


Rule  9.72;  The  elaboration  of  include  specs  is  analogous  to  the  elaboration  of  open  bindings. 


r  h^stat)  specs  'xa-  Idecs  sig  :=  [Wees] 
r,  mvav.sig;  mvar:sig  fiig  longconidi  mvar^.labsi  :  kndi 

r,  mvav.sig;  mvar:sig  fiig  longconid2  mvar'^.labs2  ■  knd2 

sig  iih  labsi  :=  labs2  sig' 
or 

sig  iih  labs2  ■=  labsi  sig' 
sig'  =  [Wees']  T  h  Idecs'  <  Idecs 

r  h^stat)  specs  sharing  type  longconidi  ~  longconid2  ^  Wees' 


(9.73) 
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Rule  9.73:  We  need  the  “or”  choice  in  this  rule  because  the  symmetric  sharing  constraint  does 
not  indicate  which  of  the  two  types  is  specified  earlier  in  the  Idecs. 


r  h^stat)  specs  Idecs  sig  :=  [Wees] 
r,  mvav.sig;  mvar:sig  fiig  longmodidi  ^  pmod^  ;  sigi 
r,  mvav.sig;  mvav.sig  fiig  longmodid2  ^  pmod2  ■  sig2 
fst{pmodi)  =  mvaP.labsi  fst{pmod2)  =  mvaP  .labs2 
sig  iih  labs  I  :=  labs 2  sig' 
or 

sig  fih  labs2  ■=  labsi  sig' 
sig'  =  [Wees']  F  h  Wees'  <  Idecs 

r  h^stat)  specs  sharing  longmodidi  ~  longmodid2  ^  Idecs' 


(9.74) 


Rule  9.74:  We  take  Fst  of  pmodi  and  pmod2  when  computing  labsi  and  labs2  in  order  to 
eliminate  any  unroll’s  of  rds’s  and  just  leave  a  sequence  of  projections. 


Signature  Expressions 


T{sigid)  =  sig 
r  h  sigid  ^  sig  :  Sig 


r  h  sigexp  sig  :  Sig 
r  fitat  sigexp  ^  statsig  :  Sig 


(9.75) 


T  (sigid)  =  sig 

F  fitat  sigid  Stat(sig)  :  Sig 

_ r  H(stat)  specs  Idecs _ 

r  l-(gtat)  sig  specs  end'^  [Wees]  :  Sig 

_ r  h(gtat)  sigexp  sig  :  Sig 

F,  modid>mvar:sig  F^gtat)  sigexp'  sig'  :  Sig 
F  F^stat)  functor  (modid  :  sigexp)  ->  sigexp'  (mvav.sig). sig'  :  Sig 


(9.76) 

(9.77) 


(9.78) 


F  F  sigexp  ^  sig  :  Sig 
F,  modid\>mvar:sig  F  sigexp'  sig'  :  Sig 
F  F  functor  (modid  :  sigexp)  -»  sigexp'  (mvav.sig). sig'  :  Sig 


(9.79) 


F  fitat  (modid  :  sigexp)  -»  sigexp'  [•]  :  Sig 


(9.80) 


_ F  Ftat  sigexp  ^  statsig  :  Sig 

F,  modid>mvar: statsig  F  sigexp  sig  :  Sig 
F  F  statsig  =  Stat(sig) 

F  F  rec  (modid)  sigexp  p(mvar).sig  :  Sig 


(9.81) 


Rule  9.81:  Note  that  the  third  premise  is  necessary  because  the  static  and  normal  elaborations 
of  sigexp  are  performed  under  different  contexts.  In  particular,  the  declaration  of  modid  in  the 
second  premise  may  shadow  earlier  declarations  of  modid  in  the  context  F,  in  which  case  the  first 
two  premises  alone  are  not  enough  to  guarantee  that  the  static  part  of  sigexp  does  not  refer  to 
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modid.  (For  instance,  observe  that  if  the  third  premise  were  omitted  and  a  type  X.t  were  visible 
in  the  context,  then  rec  (X)  sig  type  t  =  X.t  end  would  be  translated  without  complaint,  and 
the  output  would  be  ill-formed.) 


F  bat  sigexp  statsig  :  Sig 
F  bat  I'ec  (modid)  sigexp  p{statsig)  :  Sig 


(9.82) 


_  r  h(gtat)  sigexp  ^  sig  :  Sig 

F,  tyvar i\> evar I'.T ,  •  •  • ,  tyvar j^>cvarn.T  \-  ty  con  :  T 
F,  mvav.sig;  mvav.sig  bg  longconid  ^  mvar'^.labs  : 
sig  bt  iabs  :=  X{cvari,  •  •  • ,  cvarn).con  ^  sig'  F  h  sig'  <  sig 
F  h^stat)  sigexp  where  type  (tyvavi ,  ■  ■  ■  ,  tyvar^)  longconid  =  ty  ^  sig'  :  Sig 


(9.83) 


Patterns 


r  h  pat  exp  :  con  else  val  Ibnds  :  Idecs 


Rules  9.88  and  9.90  do  not  apply. 

F  h  expid  exp  :  con  else  val  expid=exp  :  expid:con 


(9.84) 


Rule  9.84:  Pattern  match  against  an  identifer  (which  is  not  a  datatype  or  exception  constructor) 
should  always  succeed. 


type  (scon)  =  con 
F  h  scon  exp  :  con  else  val 

iZa6=if  6asis. eq^o„(ea;p,  scon)  then  {}  else  raise'^"''^  val  :  ilab:\Jn\t 


(9.85) 


Rule  9.85:  Pattern  match  against  a  constant.  We  need  primitive  equality  functions  for  constants 
appearing  in  patterns. 


F  h  _  <^  exp  :  con  else  val  ^  ilab=exp  :  ilab:con 
Rule  9.86:  Pattern  match  against  a  wildcard. 

T  \-  ty  con'  :  T  F  h  con  =  con'  :  T 
F  h  pat  <^=  exp  :  con  else  val  ^  Ibnds  :  Idecs 
F  h  pat  :  ty  <^=  exp  :  con  else  val  Ibnds  :  Idecs 

Rule  9.87:  Pattern  match  against  an  explicitly-typed  pattern. 


(9.86) 


(9.87) 


P  bx  longexpid  ^  pmod.labi  :  \/{cvarp-.kndp).con  con'  =  con[conp/ccarp] 


con 


F  h  pmod.conid -Out  :  \/{cvarp:kndp).con  con 
=  S{/ab:coni, . . . ,  labn'conn}  coni  =  Unit 


F  h  conp  :  kndp 


F  h  longexpid  <^=  exp  :  con'  else  val  ^ 

ik6=pproj[°^,  [corip/cmr-p]  .  ilab:\Jr\\t 


(9.88) 


Rule  9.88:  Pattern  match  against  a  constant  datatype  constructor. 
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r  i^tx  longexpid  ^  pmod.labi  :  'i {cvarp-.kndp) .coui  — >  con 
con[  =  coni[conp/ cvavp]  con'  =  con\conp/ cvavp^ 
r  h  pmod.conid -Out  :  M {cvarp-.kndp). con 

=  'E{lahi:coni, . . . ,  labn'.conn}  T  h  conp  :  kndp 
r  h  pat  pproj^°^,  Lon^lcvarp\  else  val  ^ 

Ibnds  :  Idecs 

r  h  longexpid  pat  exp  :  con'  else  val  ^  /6nds  :  Idecs 


(9.89) 


Rule  9.89:  Pattern  match  against  a  value-carrying  datatype  constructor. 


r  l^tx  longexpid  pmod.lab  :  Tagged  P  h  pmod. tag  :  Unit  Tag 
r  h  longexpid  exp  :  Tagged  else  val  ^ 

ilab=\hagof  exp  ispmod.tag  then  Aexar:Unit.{}  else  raise^"'’^  val  :  ilab:\Jn\t 

Rule  9.90:  Pattern  match  against  a  constant  exception  constructor. 


(9.90) 


P  i^tx  longexpid  ^  pmod.lab  :  eon  Tagged 
P  h  pmod. tag  :  con  Tag 

P  h  pot  (iftagof  exp  ispmod.tag  then  Aexar:con.emr  else  raise"""  val)  :  con  else  val 
Ibnds  :  Idecs 

P  h  longexpid  pat  exp  :  Tagged  else  val  ^  Ibnds  :  Idees 


(9.91) 


Rule  9.91:  Pattern  match  against  a  value-carrying  exception  constructor. 


con  =  {recta6i:coni,  •  •  • ,  reclabn'.conn{,  ■  ■  ■)} 

Vi  €  l..n  :  P  h  potj  <^=  T^redab-  Ihndsi  :  Idecsi 


P  h  {reclabi  =  pati,  •  •  • ,  reelabn  =  po,t^{,  ■■■)'} 
Ibnds  I ,  ■  ■  ■ ,  Ibnds n  :  Idecsi,  •  •  • ,  Idees n 


exp  :  con  else  val 


(9.92) 


Rule  9.92:  Pattern  match  against  a  record  of  patterns.  The  syntactic  concatenation  of  the 
Ibndsi/ldecsi  is  implicitly  required  to  be  well- formed.  If  it  is  not,  it  means  that  the  pattern  binds 
the  same  identifier  twice,  which  is  not  permitted. 


P  h  pati  <^=  exp  :  con  else  val  Ibndsi  :  Idecsi 

P  h  pat2  exp  :  con  else  val  lbnds2  '■  ldecs2 

P  h  pati  P^l'2  ^  6xp  :  con  else  val  Ibndsi,  lbnds2  :  Idecsi,  ldecs2 

Rule  9.93:  Pattern  match  against  two  patterns  simultaneously. 


(9.93) 


P  h  pat  get  exp  :  con  else  val  Ibnds  :  Idecs 
P  h  ref  pat  exp  :  con  Ref  else  val  Ibnds  :  Idecs 

P  h  pat  exp  :  con'  else  val  Ibnds  :  Idecs 
P  h  con  =  con'  :  T 

P  h  pat  exp  :  con  else  val  ^  Ibnds  :  Idecs 


(9.94) 


(9.95) 
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Datatype  Definitions 


r  h  datbinds  ^  sig 


\/i  €  l..p,  \/k  G  l..r  : 


ilab*i:\conidi:T'^^ •  •  • ,  ilah*p:\conidp:T'^p^T\, 


T  ■.=  T Alah*>mvar'\r.  n  ,  , 

r'  :=  r',  tyvariP>cvarii:T,  •  •  • ,  tyvarin.>cvarini:T 


r"  :=  r,  ilabl>mvari:lconidi:T^^^T},  •  •  • ,  ilabp>mvarp:lconidp:T'^^ ^Tj 
Tfc  :=  r",  tyvar'f^^>cvar'f^.^:T,  •  •  • ,  tyvarA>cvarA:T 


unit 


r'  h  ^  or  >  couij  :  T  (for  j  G  l..mi)  T'l  h  ty'f.  ^  con'^  :  T 

tVij  } 

con™™  :=  S{ expirfj;^:conii,  •  •  • ,  expidij^.:conimi} 
corii  :=  {mvar^^.ilab* .conidi){cvarii,  •  •  • ,  cvavi 


siQi  := 


conidpT^^^T, 

1 

conidiAm:\/{cvarii,  •  •  • ,  cvarin. 

).conf“™  corii, 

conidi-OutN{cvarii,  ■  ■  ■ ,  cvarirn).coni  ^  con\ 

um 

5 

corii 

expidijN{cvarii,  ■■■ ,  cvarini).< 

or 

>  (for  j  G  l..mj) 

[ 

^  coriij  — >  corii  ^ 

b  J 

Ll_ 

tkndk  ;=  U{cvar'f,^,  •  •  • ,  cvar'f^^J.5{con'^) 
sig  :=  p{mvar(it).lilabl:sigi,  •  •  • ,  ilabpsigp,  conid'i'.tkndi,  •  •  • ,  conid'j.:tkndr} 


r  h  {tyvarii,  ■  ■  ■  Ayvari^p  conidi  =  expidul 

f  1 
1  1 

H  •  •  •  1 expidi^^  < 

f  1 

or  V 

1 

o 

l-h 

11  ' 

[of  tyimr) 

and  • •  •  and 

(  > 

1 

(  \ 

( tyvaXpi ,  ■  ■  ■  ,  tyvaXp^^ )  conidp  =  expidpi i 

1 

1  1 

h  •  •  •  1  expidp^^  \ 

1  1 

1 

O 

l-h 

Ip.  ' 

lof  typmj 

stg 


prrip 


withtype  {tyvar'n,  ■■■  ,tyvar[^p  conid'i  =  ty'^ 
and  •  •  •  and  ( tyvar'j.i  >  ■  ■  ■  >  tyvar'^^^ )  conid'^  =  ty'^. 

(9.96) 

Rule  9.96:  The  elaboration  of  datatype  definitions  is  actually  quite  straightforward;  the  rule 
looks  large  and  complex  mainly  because  there  are  a  number  of  different  n-ary  entities: 

•  m  =  arity  (number  of  type  arguments)  of  the  datatype  (out  of  p  datatype’s) 


•  Qk  =  arity  (number  of  type  arguments)  of  the  k^^  withtype  (out  of  r  withtype ’s) 

•  rrii  =  number  of  data  constructors  of  the  datatype 

Note  that  the  datatype’s  may  refer  to  any  of  the  datatype’s  and  any  of  the  withtype’s,  but  the 
withtype’s  may  only  refer  to  the  datatype’s,  not  to  one  another. 

Also  note  the  use  of  an  rds  in  the  output  signature  to  encode  the  dynamic-on-static  recursive 
dependencies  between  the  signatures  of  the  datatype  modules.  Having  rds’s  in  the  IL  makes  the 
encoding  of  datatype’s  here  somewhat  simpler  than  it  is  in  HS,  where  the  corresponding  rule  is 
forced  to  fake  an  rds  by  “forward-declaring”  the  datatype’s. 
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9.3.3  Canonical  Implementations  of  Signatnres 

decs  hcan  sig  ^  mod 

hcan  ^st{sig)]5{cvar  :  sig)  ^  con;  mod  cvar  0  dom(rfecs) 
mod'  :=  let  cvar=g{cvar-Pst{sig)) .con  in  {mod  :  sig)  decs  h  mod'  :p  sig 

decs  hcan  sig  mod' 

Rule  9.97;  sig  is  expected  to  only  contain  IL  translations  of  datatype  specs  and  transparent 
type  specs  (and  module  specs  containing  them).  As  outlined  in  Section  5.4,  the  basic  idea  here  is 
to  first  compute  a  canonical  implementation  of  Fst(siy)  by  joining  all  the  type  specs  in  sig  together 
under  one  big  ^-constructor.  Once  we  have  that  //-constructor,  it  is  straightforward  to  define  the 
canonical  implementation  of  sig:  type  specifications  are  implemented  by  copying  the  corresponding 
components  from  the  //-constructor,  and  the  only  value  specifications  allowed  in  sig  are  the  in  and 
out  coercions  and  data  constructors  for  datatype’s,  for  which  there  are  canonical  implementations 
using  fold’s,  unfold’s  and  sum  injections  (see  Rule  9.105). 

The  first  premise  invokes  an  auxiliary  judgment  that  computes  the  canonical  con  of  kind  fst{sig) 
and  the  canonical  mod  of  signature  sig  simultaneously,  (con  cannot  be  computed  just  based  on 
Fst(s/5)  because  the  value  specifications  in  datatype  specs  in  sig  contain  relevant  type  information 
that  is  not  in  fst{sig).)  The  auxiliary  judgment  assumes  for  convenience  that  we  use  the  same 
variable  cvar  both  for  the  variable  bound  by  the  //  and  the  variable  that  the  //  is  bound  to. 

The  last  premise  checks  that  the  output  module  is  well-formed,  which  is  tantamount  to  checking 
that  the  kind  Fst(s/y)  on  the  //-constructor  is  expandable.  See  Section  6.2  for  a  discussion  of  the 
expandability  restriction,  and  see  Section  9.3.8  for  more  on  the  consequences  of  this  restriction  for 
recursive  modules. 


(9.97) 


l“can  Icdecs;  Ideas  ^  Icbnds;  Ibnds 


This  and  the  following  auxiliary  judgments  assume  that  the  sig  or  ldec{s)  input  is  in  singleton 
form — specifically,  that  it  has  the  form  5{cpath :  sig)  or  5{cpath:ldec{s)),  where  cpath  is  a  con¬ 
structor  path  headed  by  the  //-variable  cvar  from  Rule  9.97.  Note  that  this  precondition  is  indeed 
satisfied  by  the  signature  5{cvar  :  sig)  that  is  passed  in  originally  in  Rule  9.97.  The  singleton  form 
assumption  simplifies  some  of  the  rules,  e.g.,  the  rds  rule  (Rule  9.104),  which  may  assume  the  rds 
it  is  given  is  degenerate. 


bean  ■)  ■  ') 

bean  Icdec;  Idee  Icbnd;  Ibnd 

bean  Icdccs]  Idccs  Icbnds;  Ibnds 

bean  Icdcc,  Icdccs;  Idcc,  Idecs  Icbnd,  Icbnds;  Ibnd,  Ibnds 


(9.98) 


(9.99) 


bean  Icdcc;  Idcc  Icbud]  Ibnd 


bean  lab>cvar:tknd;  lab>cvar:tknd' 

lab>cvar=Can{tknd);  lab>cvar=Car\{tknd') 


(9.100) 


Rule  9.100;  For  transparent  type  specifications,  we  can  simply  use  the  IL  Can(-)  function. 
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l“can  knd]  sig  ^  con]  mod 

hcan  lab>mvaN:knd]  lab\>mvar:sig  ^  lab>mvaN=con]  lab>mvar=mod 


(9.101) 


l“can  knd]  sig  ^  con]  mod 


hcan  Icdecs]  Idccs  Icbnds]  Ibnds 
hcan  |/cdecs];  |Zdecs]  ^  [Icbnds]]  [Ibnds] 

hcan  knd']  sig'  ^  con;  mod 
hcan  II{mvar’^:knd).knd']lT°^{mvar:sig).sig' 
A ( mvaN  And). con]  ( mvar '.sig). mod 

hcan  knd]  sig  ^  con;  mod 
hcan  knd]  p{sig)  con;  roll(morf) 


(9.102) 

(9.103) 


(9.104) 


Rule  9.104;  The  rds  is  degenerate  because  it  is  assumed  to  be  in  singleton  form. 


knd 

con 


sig 


con' 


mod 


[conidiT^^Tl 
cpath .  conid  ( cvacp ) 


conid;n(cmrp;T”).S 

(con). 

1 

confd_in;V(ct'arp;T” 

).con™™  con, 

conid_out;V(cmrp;T”).con  ^  con 

sum 

1 

con 

expidj ;  V(  cuorp ;  T” ) .  < 

or 

>  (for  j  G  l..m) 

[ 

^  conj  —>■  con  ^ 

j  J 

[  conid=X{  cvavp :  T"" ) .  con®“™] 


conid=X{cvarp:T^).con, 
conid_in=A(ccarp:T"').fold“", 
conid_out=A(ccarp:T"').  unfold™”, 


expid  j=A{cvarp:T"') 


or 

A(eTOr;conj).fold™”((inj||g 


evar))  I 

_ {j- 


hcan  knd]  sig  ^  con']  mod 


(9.105) 


Rule  9.105;  The  canonical  implementation  of  a  datatype  spec.  A  few  points  of  note; 

•  We  can  assume  that  sig  specifies  the  constructor  conid  as  transparently  equal  to  a  type  of 
the  form  cpath. conid  because  sig  is  assumed  to  be  of  the  form  5{cpath  :  sig'). 

•  This  rule  illustrates  that  it  is  necessary  to  have  sig  around  in  order  to  compute  the  output 
con' ,  because  the  definition  of  con'  comes  from  looking  at  the  types  of  conid's  in  and  out 
coercions,  which  do  not  show  up  in  the  input  knd. 

•  con'  implements  conid  as  just  a  sum  type,  not  a  recursive  sum  type;  all  the  recursive  knot- 
tying  will  be  handled  by  the  g  that  Rule  9.97  wraps  around  the  whole  constructor  at  the  very 
end. 
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9.3.4  Coercive  Signature  Matching 

decs  hiub  vpmod  :  sigQ  ^  Idecs  ^  plbnds  :  tldecs 


decs  iiub  vpmod  :  sig^  <  ■  ■ 


(9.106) 


decs  iiub  vpmod  :  sig^  <  Idee  plbnd  :  tldec 
decs,  tldec  f^ub  vpmod  :  sig^  ^  Idecs  plbnds  :  tldecs 
decs  iiub  vpmod  :  sig^  ^  Idee,  Idecs  plbnd,  plbnds  :  tldec,  tldecs 


(9.107) 


decs  hiub  vpmod  :  sig^  ^  Idee  ^  plbnd  :  tldec 


decs;  vpmod:sigQ  ^iig  lab  vexp  :  ^{cvar'p:knd'p).con' 
decs,  cvavp-.kndp  h  con'p  :  knd'p  decs,  cvavp.kndp  h  con  =  con'[con'p/ cvar'p\  :  T 

decs  iiub  vpmod  :  sig^  ^  lab>evar:y {cvavp'.kndp) . con 

lab>evar=A{cvarp:kndp).{vexp[conp])  :  lab>evar:\/{cvarp:kndp).con 


(9.108) 


Rule  9.108;  Coercion  to  a  (potentially)  polymorphic  value  specification;  this  may  involve  implicit 
polymorphic  instantiation.  Note  that  this  rule  also  handles  alpha-conversion  of  EL  type  variables, 
as  kndp  and  knd'p  need  not  have  the  same  labels  on  their  type  components. 


decs;  vpmod:sigQ  iiig  lab  con  :  knd 

decs  hiub  vpmod  :  sig^  ^  lab\>cvar:knd  ^  lab>cvar=con  :  lab>cvar:5{con  :  knd) 

Rule  9.109;  Coercion  to  a  type  constructor  specification. 

lab  is  not  open 

decs;  vpmod:sigQ  fiig  lab  vpmod'  :  sig' 
decs  iiub  vpmod'  :  sig'  ^  sig  pmod  :  tsig 
decs  hiub  vpmod  :  sig^  ^  lab\>mvar:sig  lab>mvar=pmod  :  lab>mvar:tsig 

Rule  9.110;  Coercion  to  a  module  specification. 

decs  iiub  vpmod  :  sig^  ^  sig  ^  pmod  :  tsig 
decs  iiub  vpmod  :  sig^  ^  lab*>mvar:sig  ^  lab*>mvar=pmod  :  lab* >mvar -.tsig 

Rule  9.111;  Coercion  to  an  open  module  specification,  which  means  that  vpmod  need  not  provide 
a  component  labeled  lab* ,  but  it  must  provide  all  the  components  in  the  signature  sig. 


(9.110) 


decs  hiub  vpmod  ;  sig^  ■<  sig  ^  pmod  :  tsig 


decs  hiub  vpmod  :  sig^  <  Idecs  plbnds  :  tldecs 
decs  hiub  vpmod  :  sig^  ^  pdeesj  ^  [plbnds]  :  pWees] 


(9.112) 
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decs  h^eei  vpmodQ'.sigQ  vpmod  :  lV-°^{mvari:sigi).sig'i 
decs,  mvar2'.sig2  ^iub  mvar2  '■  sig2  A  pmodi  ;  _ 

decs,  mvar2'.sig2,  mvar[:sig[[pmodi/ mvari]  iiub 

mvar'i  :  sig'ilpmodi/mvari]  ^  sig2  ^  pmod'2  :  tsig'2 
decs  iiub  vpmodQ  :  sig^  ^  lT°^{mvar2'.sig2).sig'2 

N°^{mvar2'.sig2)-9^&^f^'>^o,'<''i='^Pf^od^°^{pmodi)  \n  pmod'2  • 

( mvar2 :  s*52 )  •  tsig'2  [vpmod^°^  {pmod  i)/  mvar'.^ 

Rule  9.113;  Coercion  to  a  total  (applicative)  functor  specification. 

decs  (i^eei  vpmodQ'.sigQ  ^  vpmod  :  ir'{mvari:sigi).sig'i 
decs,  mvar2'.sig2  liub  'mvar2  :  sig2  A  sig^"^  pmodi  •  - 
decs,  mvar2'.sig2,  mvar'i:sig'i\pmodi/ mvari]  iiub 

mvar'i  :  sig'ilpmodi/ mvari]  A  sig'2  ^  pmod'2  ■  - 
decs  Iiub  vpmodfi  ;  sig^  ^  {mvar2'.sig2)-sig'2 

{mvar2'.sig2)'.sig'2.\&Y  mvar'i=vpmod'^ (pmodi)  {p'mod'2  :  sig'2)  • 
(mvar2'.sig2)-sig'2 

Rule  9.114;  Coercion  to  a  partial  (generative)  functor  specification. 


(9.113) 


(9.114) 


decs,  TO?;arstat:Stat(si5o)  iiub  muar stat  :  Stat(si5o)  ^  Stat(siff)  ^  pmodgtut  ^  - 
con  ;=  Vs\.{pmod^ig^i)^st(vpmod) / mvarlig^i\ 
decs  iiub  vpmod  :  sig^  ■<  S(con  ;  sig[con / mvar'^])  ^  pmod  :  tsig 
decs  Iiub  vpmod  :  sig^  ^  p(mvar).sig  ro\\(pmod)  :  p(tsig) 

Rule  9.115;  Coercion  to  a  recursively  dependent  signature.  The  first  premise  serves  essentially 
as  a  way  of  coercing  Fst(si5o)  to  the  kind  Fst(sig).  Instead  of  defining  a  whole  other  judgment  of 
coercive  kind  matching,  we  simply  coerce  Stat(si5Q)  to  Stat(si5')  and  then  take  Fst  of  the  coercion 
module.  (The  only  slightly  tricky  point  is  that  Stat(-)  is  not  defined  for  modules,  so  we  must  make 
up  a  module  variable  mvavstat  and  then  substitute  Fst(t;pmod)  for  it  later  on.)  This  is  a  canonical 
example  of  where  static  signatures  and  the  Stat(-)  function  come  in  handy. 

Once  we  have  a  constructor  con  of  kind  fst(sig),  we  can  coerce  to  the  body  of  the  rds  (sub¬ 
stituting  con  in  place  of  the  recursive  variable)  and  then  roll  the  coercion  module  into  the  rds. 


9.3.5  Signature  Patching 
where  type 


sig  h^t  labs  ;=  phrase  ^  sig' 


T\ (phrase)  fl  vardom(/decs)  =  0 
sig  =  {Idecs,  lab>var:elass,  Idecs'j 
sig  hvt  lab  ;=  phrase  |Wecs,  lab>var:5(phrase  :  class),  Idecs'J 

FY (phrase)  fl  vardom(/decs)  =  0 
sig  =  |/decs,  lab>mvar:sig' ,  Idecs'j 
sig'  bvt  labs  :=  phrase  sig" 
sig  hvt  lab. labs  :=  phrase  {Idecs,  lab\>mvar:sig" ,  Idecs'j 


(9.116) 


(9.117) 
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mvar  ^  TV  {phrase)  sig  =  p{mvar).sig'  sig'  labs  :=  phrase  sig" 

sig  labs  :=  phrase  p{mvar).sig" 


(9.118) 


sharing 


sig  iih  labsi  :=  labs2  ^  sig' 


sig  =  \ldees,  lab'>var':elass' ,  Idees' ,  lab>var:class,  Ideas"} 
sig  fih  lab  :=  lab'  {Ideas,  lab' \>var': class' ,  Ideas' ,  lab>var:5{var' :  class),  Idecs"} 


(9.119) 


sig  =  {Idecs,  lab' \>var' -.class' ,  Ideas' ,  lab\>var:sig" ,  Idecs"} 
sig"  labs  :=  var'  ^  sig'" 

sig  fih  lab. labs  :=  lab'  {Idecs,  lab' >var': class' ,  Idecs' ,  lab\>var:sig'" ,  Idecs"} 


(9.120) 


sig  =  {Idecs,  lab'>var':sig' ,  Idecs' ,  lab>var:sig" ,  Idecs"} 
sig"  fivt  labs  :=  var'. labs'  ^  sig"' 

sig  fih  lab. labs  :=  lab'. labs'  {Idecs,  lab'\>var':sig' ,  Idecs' ,  lab>var:sig'" ,  Idecs"} 

sig  =  {Idecs,  lab>var:sig' ,  Idecs'}  sig'  fih  labs  :=  labs'  ^  sig" 
sig  fih  lab. labs  :=  lab. labs'  {Idecs,  lab>var:sig" ,  Idecs'} 

sig  =  p{mvar).sig'  sig'  fih  labs  :=  labs'  sig" 
sig  fih  labs  :=  labs'  p{mvar).sig" 


(9.121) 


(9.122) 

(9.123) 


9.3.6  Signature  Peeling 


decs  f^eei  pmod-.sig  ^  pmod'  :  sig' 


f^eei  pmod-.sig  ^  pmod'  decs  h  pmod'  :p  sig' 
decs  hj^eei  pmod:sig  ^  pmod'  :  sig' 


(9.124) 


f]^eei  pmod-.sig  ^  pmod' 


Auxiliary  peeling  judgment,  which  strips  off  all  leading  existentials,  rds’s  and  maybe’s. 


hj^eei  pmod. visible*: sig 2  pmod' 

f]^eei  pmod:3{mvar:sigi).sig2  pmod' 

f^ieei  onro\\{pmod):sig  ^  pmod' 
f]^eei  pmod :p{mvar). sig  pmod' 

hj^eei  fetch  (pmod): sig  pmod' 
hj5eei  pmod:maybe{sig)  pmod' 

The  above  rules  do  not  apply. 
f]^eei  pmod-.sig  ^  pmod 


(9.125) 

(9.126) 

(9.127) 

(9.128) 
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9.3.7  Label  Lookup 
Context  Lookup 


r  ^  phrase  :  class 


r  i^tx  labs  con  F  h  con  :  knd 
r  f^tx  labs  con  :  knd 


(9.129) 


r  i^tx  labs  exp  T  h  exp  :  con 

r  i^tx  labs  exp  :  con 

r  i^tx  labs  pniod  T  h  pmod  :p  sig 

r  f^tx  labs  pmod  :  sig 


(9.130) 

(9.131) 


r  hjtx  labs  ^  phrase 


Auxiliary  context  lookup  judgment. 


r,  lab>cvar:knd  l^tx  lab  cvar 

lab  7^  lab'  F  l^tx  lab'  ^  phrase 
F,  labt>cvar:knd  l^tx  lab'  phrase 


(9.132) 

(9.133) 


F,  labt>evar:con  l^tx  lab  evar 

lab  7^  lab'  F  f^tx  lab'  ^  phrase 
F,  lab>evar:con  l^tx  lab'  phrase 

f]^eei  mvar-.sig  ^  pmod  lab  is  not  open 
F,  lab\>mvar:sig  l^tx  lab  pmod 


(9.134) 

(9.135) 

(9.136) 


Rule  9.136;  If  we  find  the  label  and  it  corresponds  to  a  module,  we  return  the  module  in  peeled 
form. 


lab  7^  lab'  F  htx  lab'  phrase  lab  is  not  open 
F,  lab\>mvar:sig  l^tx  lab'  phrase 

mvar-.sig  hig  lab'  ^  phrase 
F,  lab*\>mvar:sig  htx  lab'  phrase 


(9.137) 

(9.138) 


Rule  9.138:  When  we  hit  an  open  label  in  the  context,  we  switch  to  signature  lookup  in  order 
to  search  for  lab'  inside  sig. 


mvar-.sig  fiig  lab'  9A  F  htx  lab'  ^  phrase 
F,  lab*\>mvar:sig  htx  lab'  phrase 

F  l^tx  lab  pmod  :  sig  T-.,  pmod: sig  big  labs  ^  phrase  :  class 
F  btx  lab. labs  phrase 


(9.139) 


(9.140) 
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Signature  Lookup 


decs]  pmod'.sig  h^ig  labs  ^  phrase  :  class 


decs  h  pmod  :p  sig  pmod:sig  ^iig  lab  phrase  decs  h  phrase  :  class 
decs;  pmod'.sig  iiig  lab  phrase  :  class 


(9.141) 


decs]  pmod: sig  fiig  lab  pmod'  :  sig' 
decs]  pmod': sig'  fiig  labs  phrase  :  class 
decs]  pmod: sig  fiig  lab. labs  phrase  :  class 


(9.142) 


pmod: sig  fiig  lab  ^  phrase 

Auxiliary  signature  lookup  judgment,  defined  very  similarly  to  the  auxiliary  context  lookup  judg¬ 
ment. 


pmod:\ldecs,  lab\>cvar:knd\  fiig  lab  (pmod). lab 

lab  7^  lab'  pmod:lldecs}  fiig  lab'  phrase 
pmod:\ldecs,  lab\>cvar:knd\  fiig  lab'  phrase 


pmod:\ldecs,  lab\>evar:con\  fiig  lab  pmod.lab 

lab  7^  lab'  pmod:lldecs}  fiig  lab'  phrase 
pmod:\ldecs,  lab\>evar:con\  Igig  lab'  phrase 

hj^eei  pmod. lab: sig  phrase  lab  is  not  open 

pmod:\ldecs,  lab\>mvar:sig\  fiig  lab  phrase 

lab  7^  lab'  pmod: [/decs]  fiig  lab'  phrase  lab  is  not  open 
pmod:\ldecs ,  lab\>mvar:sig\  fiig  lab'  ^  phrase 

pmod. lab*: sig  fiig  lab'  phrase 
pmod:\ldecs,  lab*\>mvar:sig\  fiig  lab'  phrase 

pmod.lab*:sig  fiig  lab'  gL  pmod:\ldecs\  fiig  lab'  ^  phrase 
pmod:\ldecs,  lab*\>mvar:sig\  fiig  lab'  phrase 

unroll  (pmod):  sip  fiig  lab  phrase 
pmod: p{mvar). sig  fiig  lab  phrase 


(9.143) 

(9.144) 

(9.145) 

(9.146) 

(9.147) 

(9.148) 

(9.149) 

(9.150) 

(9.151) 


9.3.8  Recursive  Module  Elaboration 

I  will  begin  by  giving  the  elaboration  rule  for  recursive  module  expressions.  As  described  in  Sec¬ 
tion  5.4,  this  rule  elaborates  the  recursive  module  body  in  two  phases.  The  first  “static”  phase 
elaborates  only  the  static  components  of  the  module  and  produces  a  meta-signature.  In  the  second 
“main”  phase,  the  meta-signature  is  used  to  adjust  the  amount  of  type  information  revealed  in  the 
typing  context  at  different  points  during  the  typechecking  of  the  module  body. 
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r  h  modexp  ^  mod  sig 


5. 

6. 

7. 

8. 
9. 
10 


r  h  sigexp  ^  siffrec  •  Sig 

r,  modid> mv ar rec- sig j-ec  iitat  modexp  ■ 


metdsig  actual 

mvar^^c  0  FY{Stat{Pm{metasig^ctuai)))  U  FV(Stat(Pub(TOetosi5 actual))) 
r,TOuaractuai:Stat(Pub(metasi5actuai))  isub 

m?;ar actual  :  Stat(Pub(metosi5actuai))  ^  Stat(si5j.ec)  -  :  tstatsig^oen 
metasig'^^^^i  :=  metogig actual [w^ar^e^-visibleV mvar^^^] 

metogigstatic  :=  pimvarj-ec )  ■  3 (  Wf  aractual  :|  ?^e^«-S^gactual  |)  •  coerced 

r  1“  can  Priv(metogigstatic)  modgtidic 
tsiPrec  ■=  .visible*  :  gig^ec) 

©  :=  P;  mmrstatic^TOetagigstatic;  TO5dicl>m?;arrec:niaybe(tgigj,gj,) 

0  bee  unroll(m?;arstatic)-hidden  ^  modexp  ^  mo^actuai  :  is*5actuai 

11.  0,  mtiaractual-^S^^actual  ^sub  ^^l®^actual  •  ^sigactual  —  ^sipj-gf.  Pmod : 

12.  mod  :=  let  mt;arstatic=modstatic  in 

{rec{mvarrec-tsig^^c.\etmvarsctuai=modactns.\  in  (pmod coerced  : 

•  ®*5rec) 

r  h  rec  (modid  :  sigexp)  modexp  mod  ;?  gigrec 


c)) 


(9.152) 


Rule  9.152;  Let  us  consider  the  premises  one  at  a  time.  (I  suggest  the  reader  compare  the  formal 
steps  here  with  the  high-level  description  given  in  Section  5.4,  as  they  correspond  quite  closely.) 

1.  Translate  the  declared  signature  sigexp  to  sig^^^,  which  need  not  be  transparent. 

2.  Perform  static  elaboration  of  modexp,  resulting  in  the  meta-signature  me togig actual • 

3.  Enforce  the  “dynamic-on-static”  restriction  on  modexp  by  checking  that  the  recursive  module 
variable  mvar^ec  does  not  appear  in  the  static  part  of  metasig References  to  mvar^ec 
may  still  occur  in  metogig actual’s  value  specs  (i.e.,  its  datatype  specs). 

4.  We  need  to  close  up  references  to  mvar^ec  in  metasig by  enclosing  it  in  an  rds  (cf.  Fig¬ 
ure  5.17).  Unfortunately,  we  cannot  just  write  g(mtar rec )-TOetagig actual)  because  (by  step  2) 
metagigactuai  expects  mvar^^^  to  have  kind  Fst(gigree),  not  Fst(metagigactuai)-  So  first  we 
coerce  metasig into  the  shape  of  Stat(gigrec))  which  produces  tstatsig 

5-6.  Using  fgtotgig  coerced)  we  can  close  up  metasig  with  an  rds  and  call  it  metagig  static  (in 
Section  5.4,  this  was  called  CSS).  For  now,  ignore  the  box  around  metasig'^^.^^Y-  Tde  purpose 
of  the  box  will  be  explained  below  when  the  bee  judgment  is  defined. 

7.  Construct  the  canonical  module  modstatic  matching  metagig g^atic-  Note:  this  will  only  succeed 
if  Fst(Priv(metagigg^atic))  is  an  expandable  kind.  From  a  programming  perspective,  this  means 
that  if  in  modexp  there  appears  a  total  functor  expression  whose  body  contains  datatype 
definitions,  then  the  argument  signature  of  that  functor  must  not  contain  any  transparent 
type  specifications.  I  admit  this  is  a  rather  bizarre  restriction,  but  I  see  no  way  around  it. 

8.  modstatic  will  eventually  be  bound  to  mror static  (in  Section  5.4,  this  was  called  Static).  We 
can  thus  selfify  the  declared  signature  gig  rec  with  respect  to  mrar  static -visible*,  in  order  to 
obtain  a  transparent  version  of  the  declared  signature  taig rec- 
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9.  The  typing  context  0  for  the  main  phase  of  elaboration  binds  the  recursive  module  variable 
with  the  signature  maybe(tsz5j.g^).  Thanks  to  the  signature  peeling  judgment,  references  to 
modid  in  modexp  will  be  implicitly  fetch ’ed. 

10.  Perform  the  main  phase  of  elaboration,  producing  modactuai  with  signature  ts*5actuai-  Note: 

unrol  I  (mt;arstatic) -hidden  tells  the  bee  judgment  which  submodule  of  mt'or static  corresponds 
to  modexp.  (Similarly,  the  box  in  line  6  tells  the  bee  judgment  what  part  of  static 

corresponds  to  modexp.) 

11.  Match  the  actual  signature  of  the  body,  tsiffactuab  against  the  required  signature  in 

order  to  produce  a  coercion  module  pmod 

12.  Put  all  the  pieces  together  and  seal  the  result  with  the  original  declared  signature 


Static  Phase  of  Recursive  Module  Elaboration 

The  output  metaldec{s) / metasig  has  the  property  that  it  is  almost  entirely  static  and  transparent. 
The  only  construct  that  translates  to  a  metaldec  with  value  specifications  in  it  is  the  datatype 
binding  (Rule  9.158),  and  the  only  constructs  that  produce  switchable  meta-signatures  are  sealed 
module  expressions  and  recursive  module  expressions  (Rules  9.171  and  9.172).  Otherwise,  the  rules 
are  totally  straightforward. 


P  btat  •  • 


r  btat  bindings  ^  metaldecs 

(9.153) 


T  btat  sigexp  ^  sig  :  S\g  P,  sigid=sig  btat  bindings  ^  metaldecs 
P  btat  signature  sigid  =  sigexp  {;)  bindings  ^  metaldecs 


(9.154) 


P  btat  binding  ^  metaldecs  i  P,  metaldecs  i  btat  bindings  metaldecs  2 

P  btat  binding  (;)  bindings'^  metaldecs i++metaldecs2 


(9.155) 


r  ^stat  binding  ^  metaldecs 


binding  is  a  val  or  exception  binding. 
P  btat  binding  ^  ■ 


(9.156) 


binding  is  a  type  or  open  binding.  P  h  binding  tldecs 

P  btat  binding  ^  Stat(tWecs) 


(9.157) 


P  h  datbinds  ^  sig 
P  btat  datatype  datbinds  ilab*:sig 


(9.158) 


Rule  9.158;  It  is  important  here  that  the  signature  be  sig,  not  Stat(si5),  since  sig  has  a  canonical 
implementation  while  Stat(si5)  does  not. 
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r  i^tx  longconid  ^  _  :  tknd 

r  iitat  datatype  conid  =  datatype  longconid  ^  conid'.tknd 


(9.159) 


r  iitat  bindings  I  ^  metaldecsi 
T ,ilo,h*\>mvar:[metaldecsi\  ^itat  bindings2  metaldecs2 
r  fitat  local  bindings^  in  bindings2  end'^  ilab'>mvar:\nietaldecsi\,metaldecs2 


(9.160) 


r  iitat  niodexp  ^  metasig 
r  iitat  module  modid  =  modexp  modid: metasig 


(9.161) 


r  iitat  modexp  ^  metasig 


r  iitx  longmodid  ^  pmod  :  tsig 
r  iitat  longmodid  Stat{tsig) 

(9.162) 

r  iitat  bindings  ^  metaldecs 
r  iitat  struct  bindings  end  \metaldecs\ 

(9.163) 

r  iitat  modexp  ^  metasig 

r,  mvar-.metasig;  mvar-.metasig  iiig  modid  pmod  :  tsig 
modexp  is  not  of  the  form  longmodid 
r  iitat  modexp  .  modid  3{mvar:metasig) .S\.a\.{tsig) 

(9.164) 

_ r  iitat  sigexp  ^  statsig  :  Sig 

r,  modid\>mvar: statsig  iitat  modexp  ^  metasig 
r  iitat  functor  (modid  :  sigexp)  ->  modexp  ^  IT°^{mvar:statsig). metasig 


(9.165) 


r  iitat  functor  (modid  :  sigexp)  -»  modexp !•] 


(9.166) 


r  iitat  modexpi  metasigi  T  iitat  modexp2  metasig2 
T ,mvari:metasigi  h^eei  mvarp.metasigi  _  :  lT°^{mvar:statsig').tsig'' 
r,  mvari'.metasigi,  mvar2:metasig2  iiub  mvar2  :  metasig2  A  statsig'  pmod  :  _ 

r  iitat  modexp  I  (modexp  2)  3{mvari\metasigi).3{mvar2'.metasig2). 

Stat(  tsig"  [pmod  /  mvar] ) 


(9.167) 


r  iitat  bindings  ^  metaldecs 
T,ilab*>mvar:lmetaldecs}  iitat  modexp metasig 
r  iitat  let  bindings  in  modexp  end'^  3{mvar:lmetaldecs}).metasig 

r  iitat  sigexp  ^  tstatsig  :  Sig 


(9.168) 


r  iitat  modexp  seal  sigexp  tstatsig 


(9.169) 
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Rule  9.169  does  not  apply. 

r  iitat  modexp  metasig  F  iitat  sigexp  statsig  :  Sig 
r,  mvar:metasig  liub  mvar  :  metasig  ^  statsig  ^  _  :  tsig 

T  ktut  iTT-odexp  :  sigexp 3{mvar:metasig). tsig 


(9.170) 


Rule  9.169  does  not  apply. 

F  iitat  modexp  ^  metasig  F  iitat  sigexp  ^  statsig  :  Sig 
F,  mvar:metasig  iiub  mvar  :  metasig  ^  statsig  _  ;  tsig 
F  iitat  modexp  :>  sigexp  3{mvar:metasig).{pviva.te=tsig,puhlic=statsig} 

Rule  9.171:  Note  the  similarity  between  this  rule  and  the  previous  one.  The  only  difference  is 
that  the  switchable  signature  output  by  this  rule  offers  a  public,  opaque  view  of  modexp  in  addition 
to  the  private,  transparent  one.  Also  note  that  there  is  no  rule  for  impure  sealing  (unless  the  sealing 
signature  is  transparent),  since  the  body  of  a  recursive  module  is  required  to  be  pure/separable. 


F  iitat  sigexp  ^  statsig^^^  :  Sig 

F,  modid\>mvarrec- statsig iitat  modexp  metosi^actuai 

mmr^ec  ^  FV(Stat(Priv(metasi5actuai)))  U  FV(Stat(Pub(metosi5 actual))) 

F ,  mtiar  actual :  Sta  t  ( P  u  b  ( metasig  actual ) )  isub 

muor actual  :  Stat(Pub(metasi5actuai))  ^  statsig,^^  ^  _  :  tstatsig 
metasig'^^^^^^  :=  metasig / mvaP,^^] 
metosiffstatic  —  p{mvarrec)-3{mvar^tnsi-'rnetasig'^^^^^{). 

_ {private= tstatsig coerced ^  public= gtatsig ^ec I  .g  ^,^2) 

F  iitat  3:ec  (modid  :  sigexp)  modexp  metasig 

Rule  9.172:  The  premises  of  this  rule  are  almost  identical  to  the  first  six  premises  of  Rule  9.152, 
which  makes  sense  since  static  elaboration  is  the  first  phase  of  recursive  module  elaboration.  The 
only  significant  difference  is  that  here  metosif/g^atic  offers  a  public,  opaque  view  of  the  recursive 
module  in  addition  to  the  private,  transparent  one. 

Main  Phase  of  Recursive  Module  Elaboration 

The  judgments  describing  the  main  phase  of  recursive  module  elaboration  make  use  of  a  spe¬ 
cial  “meta-context”  0  of  the  form  T]  metadec;T' .  Here,  metadec  is  a  declaration  of  the  form 
rmiarstatic^^Tretasi^g^atic)  where  metasig represents  the  product  of  the  static  phase  of  recursive 
module  elaboration.  It  is  important  that  0  contain  the  full  metasig g^atic  not  just  its  public 
setting,  because  we  will  want  to  actually  switch  some  of  the  settings  in  metasig from  public  to 
private  during  elaboration.  Wherever  I  use  a  meta-context  0  =  F;  metadec;T'  in  a  premise  that 
expects  a  normal  elaboration  context,  0  should  be  implicitly  erased  to  F,  Pub(TOetodec),  F'. 

What  makes  the  main  phase  somewhat  tricky  to  formalize  is  that  we  need  to  keep  track  of  what 
part  of  metasigg^a^jj,  (and,  similarly,  what  projection  from  mt'ar static)  corresponds  to  the  piece  of 
the  recursive  module  body  we  are  currently  elaborating.  The  translation  judgments  have  the  form 
0  hec  pmod  =>  binding{s)  Ibnds  :  tldecs  and  0  hec  pmod  modexp  mod  :  tsig.  The  input 
pmod  tells  us  where  we  are  in  mvar  static-  Specifically,  pmod  will  have  the  form  of  a  “path” — i.e.,  a 
sequence  of  eliminations  {i.e.,  projections,  applications,  unroll’ings) — headed  by  mvarstatic- 
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To  indicate  where  we  are  in  I  will  employ  the  simple,  if  unusual,  technique  of 

surrounding  it  with  a  box  (literally).  When  the  judgment  makes  a  recursive  call  on  a  subterm, 
the  box  will  shrink  in  order  to  enclose  only  the  meta-signature/meta-declaration(s)  in  metasig 
corresponding  to  that  subterm.  In  many  of  the  rules,  it  is  useful  to  be  able  to  “zoom  in”  on 
the  part  of  metasig that  is  boxed.  To  enable  this,  I  will  write  metadec{  metasig  }  (resp. 
metadecW  metalda^)  to  signify  that  metasig  (resp.  metaldecs)  is  the  boxed  part  of  metasig 

Aside  from  keeping  track  of  where  we  are  in  metasig which  is  totally  straightforward, 
most  of  the  rules  are  very  similar  to  the  normal  elaboration  rules  for  bindings  and  module  expres¬ 
sions.  The  constructs  whose  rules  are  most  interesting  are  those  that  involve  some  form  of  data 
abstraction — namely,  datatype  bindings,  sealed  module  expressions  and  recursive  module  expres¬ 
sions  (Rules  9.178,  9.188  and  9.189).  While  recursive  module  elaboration  respects  data  abstraction 
boundaries  during  typechecking,  the  output  of  recursive  module  elaboration  is  transparent,  so  that 
the  recursive  module  body  will  match  the  transparent  declared  signature  {tsig^^^  in  Rule  9.152). 


0  Ivec  pmod  =A  bindings  ^  Ibnds  :  tldecs 


0  =  T;  metadec{[^};  T' 
0  hec  pmod  • 


(9.173) 


0  h  sigexp  ^  sig  :  Sig  0,  sigid=sig  l^ec  pmod  bindings  Ibnds  :  tldecs 
0  hec  pmod  signature  sigid  =  sigexp  (;)  bindings  Ibnds  :  tldecs 


(9.174) 


0  =  T;  metadec{  metaldecs metaldecs 2  };r' 


T;  metadec{  metaldecs i ,  metaldecs 2} ',T'  hec  pmod  =>  binding  Ibnds i  :  tldecs i 
T;  metadec {metaldecs I ,  metaldecs2  |;  T',  tldecsi  hec  pmod  bindings  lbnds2  ■  tldecs2 


0  hec  pmod  binding  (;)  bindings  Ibnds i++lbnds2  '■  tldecs i++ tldecs 2 


(9.175) 


0  lyec  pmod  A-  binding  ^  Ibnds  :  tldecs 


binding  is  a  val  or  exception  binding. 
0  =  T;  metadec{[^};  T' 

0  h  binding  ^  Ibnds  :p  tldecs 
0  hec  pmod  =>  binding  Ibnds  :  tldecs 


(9.176) 


Rule  9.176;  For  val  and  exception  bindings,  there  is  no  static  part  (the  box  in  0  is  empty), 
and  we  default  to  using  normal  elaboration. 


binding  is  a  type,  open  or  datatype  replication  binding. 

0  =  T;  metadec{\metalde^}\ T^ 

0  h  binding  Ibnds  :p  tldecs 
length  (metaWecs)  =  length  (tWecs) 

0  hec  pmod  =>  binding  Ibnds  :  tldecs 

Rule  9.177;  For  these  atomic,  transparent  bindings,  we  can  default  to  normal  elaboration.  The 
last  premise  ensures  that  the  box  in  0  encloses  the  right  number  of  metaldecs. 
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0  =  F;  metadec{  ilab*:sig'  };  F' 


0  h  datbinds  sig  0  h  pmod.ilab*  :  sig 
0  f^ec  pmod  datatype  datbinds 

ilab*=  pmod.ilab*  :  ilab*:5 {pmod.ilab*  :  sig) 


(9.178) 


Rule  9.178;  For  a  datatype  binding,  we  know  that  the  static  phase  has  already  computed  the 
datatype  module.  We  can  therefore  copy  the  module  directly  from  pmod  (cf.  Figure  5.20). 


0  =  F;  metadec{  ilab:lmetaldecs ij,  metaldecs2  };F' 


F;  metadec{ilab:l  metaldecsi  ],  metaldecs2}‘,  F'  fY( 


pmod.ilab  bindings i  Ibndsi  :  tldecs\ 


F;  metadec{ilab:lmetaldecs i},  metaldecs2  };F',  ilab*>mvar:ltldecsil  be. 
pmod  bindings  2  lbnds2  '  tldecs2 
0  bee  pmod  =>  local  bindings^  in  bindings2  end'^^ 

ilab>mvar=[lbndsi],  lbnds2  ■  ilab>mvar:ltldecsil,  Udecs2 


(9.179) 


0  =  F;  metadec{  lab:metasig  };  F' 

F;  metadec{lah:  metasig  };  F'  bee  pmod. lab  ^  modexp 


mod  :  tsig 


0  bee  pmod  module  modid  =  modexp  modid=mod  :  modid:tsig 


(9.180) 


0  bee  pmod  modexp  ^  mod  :  tsig 


0  =  F;  metadec{  tsig'  };  F' 
0  h  modexp  ^  mod  tsig 


0  bee  pmod  modexp  ^  purify(mod)  :  tsig 


(9.181) 


Rule  9.181:  If  the  boxed  signature  in  0  is  a  normal  transparent  signature,  then  we  can  use  the 
same  0  for  typechecking  all  of  modexp  and  default  to  normal  elaboration. 

Rules  9.182“-9.188  assume  that  the  highlighted  signature  in  0  is  not  transparent,  in  which  case 
Rule  9.181  does  not  apply. 


0  =  F;  metadec{\lmetaldecs}\\]T' 


F;  metadecil\metaldecs\}};  F'  bee  pmod  bindings  Ibnds  :  tldecs 
0  bee  pmod  struct  strdec  end  [Ibnds]  :  [tWees] 


(9.182) 


0  =  F;  metadeeI^-^{mvar-.metasig).sig^;T' 

modexp  mod  :  tsig 


F;  metadec{3{mvar:  metasig  ).si5};F'  bee  pmod. hidden 

pmod'  :  tsig' 


0,  mvar:tsig]  mvav.tsig  big  modid 


0  bee  pmod  modexp  .  modid  ^  elet  mvar=mod  \npmod'  :  3{mvar Tsig) .tsig' 


(9.183) 
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0  =  T;  metadec{\lT°^{mvar:sig').metasig\};T' 


0  h  sigexp  sig  :  Sig 


F;  metadec{lT°^ {mvar:sig') .  metasig  };  F',  modid>mvar:sig  i^e 
pmod{mvar)  modexp  ^  mod  :  tsig 
0  f^ec  pmod  functor  {modid  :  sigexp)  ->  modexp 
{mvar:sig) .mod  :  YT°^{mvar\ sig). tsig 


(9.184) 


Rule  9.184;  This  rule  handles  total  functors.  Partial  functors  are  handled  by  Rule  9.181,  since 
a  partial  functor  is  considered  transparent. 


0  =  T-.,metadec{3{mvari:metasigi).3{mvar2'.metasig2).sig}-.,T' 


F;  metadec{3{mvari:  metasigi  ).3{mvar2:metasig2).sig}]T'  he 
pmod. hidden  ^  modexp i  modi  ■  isigi 

F;  metadec{3{mvari:metasigi) 


pmod.  visible*. hidden 


).3{mvar2:  metasig2  ).sig}]  F'  he 
modexp  2 


^  mod2  ;  tsig2 

0,  mvari'.tsigi  f^^eei  mvari'.tsigi  ^  pmodi  :  lT°^{mvar:sig').tsig" 
0,  mvari'.tsigi,  mvar2'.tsig2  hub  mvar2  :  tsig2  A  sig'  ^  pmod2  '■  - 


0  hec  pmod  modexp  I  (modexp  2) 

elet  mvari=modi  in  elet  mvar2=mod2  in  pmod  1°^ {pmod 2)  '■ 
3{mvari-.tsigi).3{  mvar  2'.tsig2).tsig"[pmod2/ mvar] 


(9.185) 


Rule  9.185;  We  only  allow  applications  of  total  functors;  partial  functor  applications  are  impure. 


0  =  T;  metadec{3{mvar :\metaldecsY). metasig  };T' 


F;  metadec\3{mvar:\\metaldecs\\].metasiQ\\ F'  he 
pmod. hidden  =>  bindings  Ibnds  :  tldecs 


F;  metadec{3{mvar:lmetaldecs}).  metasig  };F',  ilab*\>mvar:\tldecs\  he 
pmod. visible*  modexp  ^  mod  ;  tsig 

0  hec  pmod  let  bindings  in  modexp  end 

elet  mvar=[lbnds\  in  mod  ;  3{mvar-.[tldecs\).tsig 


(9.186) 


0  =  T;metadec{3{mvar:metasig).sig' 

F;  metadec{3{mvar:  metasig  ).sig'}]T'  hec  pmod. hidden  =>  modexp  mod  ;  tsig 

0  h  sigexp  ^  sig  ;  Sig 

0,  mvar -.tsig  hub  mvar  :  tsig  ^  sig  pmod'  :  tsig' 

0  hec  pmod  modexp  :  sigexp  ^  elet  mvar=mod  in  pmod'  ;  3{mvar:tsig) .tsig' 


(9.187) 
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0  =  F;  metadec{  3{mvar:metasig).{pii-vate=tsigN^^^^^,  };  F' 


0  h  sigexp  ^  siffpubiic  :  Sig 

^■s^^pubiic  •=  5 {pmod. visible*  :  s*5pubiic)  ©  ^  Fst(pmorf). visible*  ;  Fst(si5pubiic) 
©private  :=  T;  me todec {3 ( mvar-\metasig  |) . } ;  F^ 


©private  ^Tec  pmod .Ridden  modexp  modactual  :  ^S*5actual 
©private;  actual  ^ub  niVCLT  .  actual  —  ^^^^public  coerced  • 

0  f^ec  pmod  modexp  :  >  sigexp  ^ 

let  mVCLT  ftlOtiactual  (^O*^coerced  •  ^^^^public)  •  ^^^^public 


(9.188) 


Rule  9.188:  Two  important  points;  (1)  When  we  go  beneath  the  sealing  to  elaborate  modexp^ 
we  use  a  modified  meta-context  0private  in  which  the  public  signature  of  pmod .visihie*  is  eliminated 
and  only  the  private  one  remains.  0private  exposes  the  implementation  of  modexp  by  allowing  us 
to  observe  the  connection  between  the  type  components  of  pmod. visible*  and  pmod. hidden  that 
0  obscured.  (2)  The  output  signature  is  not  siPpubiic  but  rather  the  selfification  of  s*5pubiic  with 
respect  to  pmod. visible*  (cf.  Figure  5.22).  The  purpose  of  this  is  to  allow  the  code  outside  of 
modexp  :  >  sigexp  to  observe  that  the  type  components  of  this  module  expression  are  equivalent  to 
those  of  pmod. visible*,  thus  avoiding  the  double  vision  problem.  However,  the  private  implemen¬ 
tation  of  modexp  is  still  kept  hidden,  because  the  signature  that  the  rest  of  the  recursive  module 
body  sees  for  pmod. visible*  is  the  public  one. 


0  =  F;  metadec{  p{mvarrec)-3{mvar:meta.sig).{piivate=tsigN^^^^^,public=sigp^^Y^^}L;T' 


tsigj. 


0  F  sigexp  sipj.^^  :  Sig 

:=  S(unroll(pmod). visible*  :  sig^^^)  0  F  Fst(pmod). visible*  :  Fst(si(/,. 


©private  :=  T]  metadec{p{mvarrec)-3{mvar-\metasig\).tsigN^^Yj 

;  F',  modidi>mmrrec:maybe(fsi5j.gc) 

©private  hec  u nrol I (pmod). hidden  ^  modexp  mod actual  :  actual 

©private;  ™'*^®^actual •  tsip actual  ^ub  ^'*^®^actual  •  actual  —  coerced  •  — 

0  Fee  pmod  ^  rec  {modid  :  sigexp)  modexp  ^ 

rec(mt;ari.ecTs«Prec-let  mtiar actual  =  Wodactual  in  (pmod coerced  :  ^S^drec))  :  is^drec 


(9.189) 


Rule  9.189;  Just  as  the  static  elaboration  rule  for  recursive  modules  performed  the  first  half 
of  Rule  9.152,  the  present  rule  performs  the  last  half.  The  only  additional  point  is  that  recursive 
module  expressions  are  implicitly  sealed  with  their  declared  signatures.  Thus,  when  elaboration 
goes  inside  the  recursive  module,  we  must  modify  the  context  (in  the  same  way  as  in  Rule  9.188)  in 
order  to  expose  the  private  connection  between  the  type  components  of  unroll  (pmod).  visible*  and 
u  n  rol  I  (pmod ) . hidden. 


9.4  Notes  on  Implementation 

A  clear,  formal  language  definition  is  indisputably  useful,  but  it  can  also  conceal  certain  issues  that 
cause  serious  problems  for  practical  implementation.  In  order  to  demonstrate  the  viability  of  my 
language  design  ideas,  I  have  implemented,  as  an  experimental  alternate  front  end  to  the  TILT 
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compiler,  a  language  similar  to  the  one  defined  in  this  chapter.  The  language  I  implemented  is  not 
exactly  the  same  as  the  one  presented  here,  partly  because  the  implementation  was  based  on  an 
earlier  formalization  and  partly  due  to  time  constraints  on  my  implementation  work.  Fortunately, 
the  recursive  module  and  recursively  dependent  signature  constructs,  which  are  arguably  the  most 
useful  and  semantically  complex  of  all  the  new  features  in  my  language,  are  implemented  in  a  way 
that  follows  the  present  formalization  very  closely.  Furthermore,  my  limited  testing  has  shown  the 
implementation  to  exhibit  the  intended  behavior  on  all  the  examples  of  Chapter  5. 

Most  of  the  differences  between  my  implementation  and  the  present  formalization  are  with  re¬ 
gard  to  superficial  choices  of  surface  syntax.  In  particular,  while  I  have  felt  free  in  this  chapter  to 
revise  SML  syntax  as  I  see  fit — e.g.,  supporting  module  bindings  as  opposed  to  SML’s  structure 
and  functor  bindings — my  implementation  sticks  closer  to  SML  syntax  in  order  to  provide  back¬ 
ward  compatibility  with  existing  SML  code  bases.  However,  there  are  a  few  more  significant 
distinctions  worth  mentioning. 

First,  my  implementation  does  not  support  the  packtype  mechanism,  nor  does  it  provide  any 
other  mechanism  for  packaging  modules  as  hrst-class  values.  The  reason  for  this  is  pragmatic: 
whereas  I  found  that  recursive  modules  constituted  a  relatively  orthogonal  extension  to  the  TILT 
compiler  (and  mostly  just  to  the  front  end),  supporting  package  types  and  first-class  module  values 
would  have  required  me  to  make  major  changes  to  the  whole  compiler. 

To  understand  why,  observe  that  in  the  absence  of  pack  mod  as  sig  and  unpack  exp  as  sig,  the 
IL  has  a  purely  second-class  module  system.  That  is  to  say,  the  type  system  may  distinguish 
“separable”  modules  from  “inseparable”  modules,  but  in  truth  there  is  no  way  for  the  underlying 
type  components  of  a  module  to  depend  on  any  dynamic  values  or  effects.  As  a  consequence,  it 
is  possible  to  phase-split  all  modules,  not  just  separable  modules,  into  a  type  constructor  and  a 
term,  by  simply  ignoring  all  uses  of  sealing  and  translating  partial  functors  in  the  same  way  as  total 
functors.  As  Standard  ML  has  a  purely  second-class  module  language,  the  original  TILT  front  end 
takes  precisely  this  approach,  and  all  the  intermediate  stages  of  the  compiler  are  designed  to  work 
with  code  that  has  been  phase-split  in  this  way.  Rather  than  change  an  assumption  of  the  whole 
compiler,  I  opted  to  follow  TILT’s  approach  to  phase-splitting  and  omit  first-class  module  packages 
from  the  implementation,  at  least  for  the  time  being. 

Second,  as  I  discussed  in  Section  2.2.1,  an  unfortunate  deficiency  of  all  existing  dialects  of  the 
ML  module  system  (including  the  one  in  this  thesis)  is  their  lack  of  support  for  inseparable  sealing 
and  statically  total  functors.  In  the  earlier  language  design  on  which  my  implementation  is  based, 
I  attempted  to  remedy  this  dehciency.  My  idea  was  to  have  separably  total  functors  behave  more 
like  statically  total  functors  by  making  static  module  equivalence  so  conservative  that  it  implies 
dynamic  equivalence.  Specihcally,  I  had  the  elaborator  automatically  insert  into  every  structure 
expression,  struct  bindings  end,  a  sealed  submodule  defining  an  abstract  “identity”  type.  The 
effect  of  these  identity  types  is  to  render  two  modules  statically  equivalent  only  if  their  identity 
types  are  equivalent,  which  in  turn  is  only  the  case  if  they  are  syntactically  identical  or  one  is  a 
renaming  of  the  other  {e.g.,  structure  X  =  Y).  In  essence,  this  is  a  generalization  of  the  approach 
taken  by  O’Caml,  which  is  not  as  brittle  as  O’Caml’s  syntactic  equivalence  because  it  allows  for 
renamings  of  modules. 

However,  as  I  also  discussed  in  Section  2.2.1,  syntactic  equivalence  does  not  always  imply 
dynamic  equivalence.  For  instance,  the  functor  application  F(X)  is  syntactically  equivalent  to 
itself,  yet  it  may  be  dynamically  impure  and  generate  different  value  components  each  time  it  is 
evaluated.  Since  static  equivalence  in  the  presence  of  identity  types  is  a  strict  generalization  of 
O’Caml’s  syntactic  equivalence,  it  does  not  imply  dynamic  equivalence  either.  In  preparing  the 
language  design  of  this  thesis,  I  decided  to  dispense  with  identity  types  and  the  muddled  semantics 
that  results  from  them. 
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That  said,  the  identity  types  did  have  some  considerable  practical  benefits  in  terms  of  imple¬ 
mentation.  First,  when  comparing  the  static  parts  of  two  modules  for  equivalence,  elaboration 
invariants  guaranteed  that  the  modules  would  be  statically  equivalent  if  and  only  if  their  identity 
types  were  equivalent.  This  greatly  simplihed  the  implementation  of  the  type  equivalence  subrou¬ 
tine  used  by  the  elaborator.  Second,  since  all  anonymous  structure  expressions  were  elaborated  to 
modules  containing  sealed  submodules,  the  only  projectible  modules  were  those  in  O’Caml-style 
named  form  {e.g.,  F(X)  .A).  As  a  result,  the  sizes  of  types  projected  from  modules  remained  rela¬ 
tively  small.  In  an  implementation  of  the  language  defined  in  this  chapter,  it  may  be  necessary  for 
the  elaborator  to  insert  extra  type  abbreviations  to  ensure  that  types  do  not  blow  up  in  size. 

In  general,  type  size  and  type  duplication  are  serious  issues  that  are  easy  to  overlook  when 
formalizing  the  language.  One  notable  example  of  type  duplication  that  I  encountered  was  in  the 
elaboration  of  datatype  definitions.  In  Rule  9.96,  the  sum  type  that  appears  in  the  types  of 

the  datatype’s  in  and  out  coercions  is  never  bound  to  a  type  identifier.  Thus,  in  Rule  9.20,  which 
elaborates  datatype  constructor  applications  by  inlining  them,  the  sum  injection  in  the  output 
of  the  rule  is  forced  to  include  a  duplicate  copy  of  its  target  con®“™  type.  This  means  that  the 
large  type  corresponding  to  a  large  datatype  will  be  duplicated  everywhere  one  of  its  many 

constructors  is  used  in  the  program. 

The  TILT  compiler  addresses  this  issue  by  adding  to  every  datatype  module/signature  a  “sum” 
component  specihed  as  transparently  equal  to  the  corresponding  con™™  type,  so  that  subsequent 
references  to  con™™  can  be  replaced  by  references  to  the  datatype’s  “sum”  component.  This 
solution  works  fine  for  SML,  but  causes  problems  with  the  use  of  datatype  specs  in  recursively 
dependent  signatures.  According  to  the  semantics  of  this  chapter,  datatype  definitions  in  an  rds 
p{mvar).sig  are  permitted  to  refer  to  mvaN  because  such  references  will  always  emanate  from  value 
specifications  and  thus  obey  the  dynamic-on-static  restriction.  However,  with  TILT’s  addition 
of  transparent  sum-type  components  to  datatype  specs,  a  reference  to  mvaN  from  a  datatype 
definition  will  imply  a  reference  from  its  sum-type  component,  which  is  not  dynamic-on-static. 

I  addressed  this  problem  in  the  implementation  as  follows.  First,  I  observed  that,  in  signatures 
output  by  the  elaborator,  the  specification  of  a  normal  (non-” sum”)  type  component  of  a  signature 
never  refers  to  any  “sum”  components.  Consequently,  it  is  possible  to  phase-split  every  signature  sig 
into  three  parts  \cvari:kndi.  cvar2'-tknd2-  con],  where  sig’s  type  components  are  divided  between 
kndi,  which  contains  the  specifications  of  its  normal  type  components,  and  tknd2,  which  contains 
the  (transparent)  specifications  of  its  “sum”  type  components.  As  the  syntax  suggests,  tknd2  may 
refer  to  cvari,  and  con  may  refer  to  cvari  and  cvar2,  but  kndi  may  refer  to  neither. 

The  upshot  is  that,  if  an  rds  p{mvar'^).sig  contains  static-on-static  references  from  datatype 
specs  in  sig  to  mvar’^,  these  will  always  be  references  from  the  knd2  part  of  sig  to  the  kndi  part.  As 
such,  they  are  fundamentally  acyclic  dependencies,  and  it  is  possible  to  compile  such  rds’s  without 
requiring  equi-recursive  types.  Unfortunately,  in  order  to  phase-split  these  more  flexible  rds’s,  I  was 
forced  to  modify  the  entire  TILT  phase-splitter  in  order  to  generate  three-part  output.  Hopefully, 
in  future  work,  we  will  be  able  to  use  three-part  phase-splitting  in  a  more  general  fashion,  e.g.,  to 
allow  rds’s  to  contain  any  kind  of  static-on-static  dependency  that  is  fundamentally  acyclic,  in  the 
way  that  O’Caml’s  recursive  module  extension  does. 

Finally,  while  the  need  to  control  type  duplication  resulted  in  certain  complications  to  my 
implementation,  I  would  say  that  overall  the  benefits  of  targeting  a  typed  intermediate  language 
outweighed  the  frustrations.  The  TILT  intermediate  language  typechecker  helped  me  uncover 
various  small  bugs  in  my  implementation,  and  in  one  notable  instance  it  pointed  to  a  serious 
error  in  an  earlier  formalization  of  my  Lean  judgment  for  computing  canonical  implementations  of 
signatures. 


Chapter  10 


Conclusion  and  Future  Work 


10.1  Conclusion 

The  ML  module  system  stands  as  a  high-water  mark  of  programming  language  support  for  data 
abstraction.  I  began  my  work  toward  this  dissertation  by  investigating  how  to  extend  ML  with 
recursive  modules,  with  the  goal  of  enhancing  its  support  for  data  abstraction  even  further.  In  the 
course  of  my  investigation,  I  have 

•  Constructed  a  unifying  account  of  the  ML  module  system,  in  which  the  existing  ML  dialects 
can  be  understood  as  subsystems  that  pick  and  choose  different  features 

•  Designed  a  recursive  module  extension  to  this  unifying  account  that  addresses  methodological 
problems  with  current  recursive  module  proposals,  encourages  the  use  of  data  abstraction 
mechanisms  in  recursive  modules,  and  is  easy  to  explain  to  the  programmer 

•  Formalized  this  design,  using  Harper  and  Stone’s  interpretation  of  Standard  ML  as  a  model 
for  developing  a  significant  portion  of  the  language  in  the  framework  of  type  theory 

I  have  also  studied  the  problem  of  statically  detecting  whether  recursion,  under  the  backpatching 
semantics  used  for  recursive  modules,  is  safe.  I  have  proposed  a  promising  type  system  for  this 
purpose  that  improves  considerably  on  existing  approaches  and  enables  more  efficient  compilation 
of  recursive  modules.  However,  as  described  in  Section  7.6,  future  work  still  remains  with  regard 
to  type  inference  and  type  system  complexity  before  my  proposal  can  be  feasibly  incorporated  into 
ML. 

I  hope  that  my  unifying  conception  of  ML  modules,  as  well  as  my  thorough  analysis  of  the 
recursive  module  problem,  may  serve  as  a  helpful  guide  to  researchers  and  programmers  alike  in 
their  attempts  to  understand  the  key  issues  and  choices  in  the  design  of  the  ML  module  system. 
Although  my  thesis  culminates  in  the  definition  of  a  new  ML  dialect,  this  language  is  most  certainly 
a  work  in  progress,  and  should  by  no  means  be  taken  as  the  final  word  on  ML  or  its  module  system. 
Rather,  I  hope  that  this  language  will  serve  as  a  foundation  for  future  work,  that  its  limitations  will 
inspire  further  evolution  of  the  ML  module  system,  and  that  its  formalization  in  a  type-theoretic 
framework  will  encourage  others  to  follow  suit. 
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10.2  Future  Work 

In  addition  to  the  future  work  on  safe  recursion  discussed  in  Section  7.6,  some  interesting  avenues 
for  future  work  include  the  following; 

Separate  Compilation  of  Recursive  Modules  One  major  omission  of  existing  recursive  mod¬ 
ule  proposals  that  my  language  of  Part  III  does  not  address  in  its  present  form  is  support  for 
separate  compilation  of  mutually  recursive  modules.  ML  provides  support  for  separate  compilation 
of  normal — i.e.,  hierarchically-dependent — modules  through  the  functor  mechanism.  However,  as 
explained  in  Section  5.2.4,  functors  are  not  sufficient  to  handle  separate  compilation  of  recursive 
modules  because  recursive  modules  require  a  special  kind  of  elaboration  in  order  to  deal  with  the 
double  vision  problem. 

Does  this  imply  that  separate  compilation  of  recursive  modules  is  hopeless?  Not  at  all.  The 
primary  innovation  of  my  recursive  module  construct  is  that  it  respects  data  abstraction.  If  mu¬ 
tually  recursive  modules  are  sealed  with  abstract  interfaces,  then  each  module  is  typechecked  in  a 
separate  context,  which  exposes  its  own  implementation  but  hides  the  implementation  of  the  other 
module.  It  should  be  straightforward  to  adapt  recursive  module  elaboration  in  order  to  eompile 
these  modules  separately  as  well,  but  such  a  separate  compilation  mechanism  is  not  encodable  in 
terms  of  the  existing  mechanisms  of  my  external  language. 

As  a  practical  matter,  I  believe  that  the  most  appropriate  way  to  introduce  such  a  mechanism 
is  as  part  of  a  compilation  management  system  built  on  top  of  ML.  Although  the  Definition  of 
Standard  ML  does  not  specify  anything  regarding  compilation  management,  most  implementations 
provide  some  facility  that  enables  programs  to  be  split  into  compilation  units  and  that  supports 
incremental  recompilation  of  those  units.  TILT  additionally  provides  support  for  “true”  separate 
compilation — any  compilation  unit  may  be  compiled  independently  of  its  imports,  so  long  as  the 
programmer  explicitly  specifies  the  signatures  of  those  imports.  Formalizing  the  semantics  of  com¬ 
pilation  units  by  elaboration  into  the  ML  internal  language  would  be  a  useful  contribution  in  its 
own  right,  and  it  should  be  possible  in  such  a  semantics  to  use  my  recursive  module  elaboration 
techniques  in  order  to  support  recursive  dependencies  between  separate  compilation  units. 

Refining  the  Total/Partial  Distinction  In  my  module  framework,  the  distinction  between 
total  and  partial  functors  is  sufficiently  general  to  account  for  the  kinds  of  functors  found  in  the 
existing  variants  of  the  ML  module  system,  but  it  is  easy  to  imagine  more  subtle  gradations. 
For  example,  one  may  want  to  write  a  functor  F  whose  body  contains  two  submodules  A  and  B, 
wherein  A  contains  only  uses  of  basic  sealing  while  B  contains  uses  of  impure  sealing.  Under  my 
present  semantics,  F  will  be  deemed  partial  because  of  B’s  impurity,  but  this  is  more  restrictive  than 
necessary.  It  would  be  more  accurate  to  treat  F  as  partial  with  respect  to  the  type  components  of 
B  and  total  with  respect  to  the  type  components  of  A. 

Another  way  in  which  my  functor  semantics  is  perhaps  overly  coarse  is  that  it  assumes  that 
the  body  of  a  functor  depends  on  the  entire  argument  module.  Suppose  that  the  argument  X  of 
the  above  functor  F  has  itself  two  submodules  A  and  B,  and  that  the  module  A  in  F’s  body  depends 
only  on  types  projected  from  X.A,  not  X.B.  In  that  case,  it  might  be  useful  to  observe  that,  when  F 
is  applied  to  two  argument  modules  with  equivalent  A  components,  the  A  components  in  the  result 
will  be  equivalent  as  well,  regardless  of  what  the  arguments’  B  components  were. 

It  is  worth  exploring  whether  either  of  these  refinements  to  the  total/partial  distinction  can  be 
incorporated  into  my  present  framework  without  introducing  semantic  complexity  disproportionate 
to  their  practical  utility. 
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Regaining  “Statically  Total”  Functors  It  is  unfortunate  that  all  existing  dialects  of  the  ML 
module  system,  including  my  own,  only  distinguish  between  separably  total  and  partial  functors, 
because  the  “statically  total”  classification  is  preferable  to  both  in  many  cases  like  the  Set  functor. 
However,  in  order  to  support  statically  total  functors,  as  well  as  the  related  mechanism  of  insepara¬ 
ble  sealing,  we  appear  to  require  some  form  of  dependent  type.  For  example,  we  would  like  to  treat 
the  Set  functor  as  statically  total  because  it  should  only  return  compatible  type  components  when 
applied  to  dynamically  equivalent  results.  What  this  means,  though,  is  that  the  type  Set(X)  .t 
depends  on  the  dynamic  components  of  the  argument  X  and  is  thus  a  kind  of  dependent  type. 

As  I  explained  in  Section  2.2.1,  the  O’Caml  functor  mechanism  is  an  interesting  case.  It  uses 
syntactic  equivalence  to  compare  functor  arguments,  which  in  many  (but  not  all)  cases  implies 
dynamic  equivalence.  Consequently,  O’Caml  functors  behave  on  many  (but  not  all)  arguments 
as  if  they  were  statically  total.  It  remains  an  open  problem  whether  it  is  possible  to  develop  a 
mechanism  that  mimics  the  semantics  of  statically  total  functors  on  all  arguments,  without  the 
need  for  actual  dependent  types. 

Data  Abstraction  with  Multiple  Principals  Mb’s  sealing  mechanism  allows  the  implementor 
of  a  module  to  hide  information  from  the  clients  of  that  module,  i.e.,  the  rest  of  the  program.  While 
the  extensions  to  ML  I  have  given  in  this  thesis  do  not  fundamentally  change  this  implementor /client 
model  of  data  abstraction,  a  useful  direction  for  future  work  may  be  to  generalize  this  model.  There 
may  be  many  modules  in  a  program,  and  the  implementor  of  a  module  A  may  wish  to  expose  its 
implementation  details  to  certain  modules  (Bi, . . .  ,8^^)  but  not  to  other  modules  (Ci, . . . ,  Cn).  In 
ML,  this  can  be  awkward  to  achieve.  A  cannot  be  sealed  right  where  it  is  bound  because  that  would 
hide  its  implementation  from  the  B  modules.  Instead,  A  and  the  B’s  must  be  defined  together  as 
submodules  of  some  larger  module  AB,  and  then  AB  can  be  sealed  to  hide  implementation  details 
from  the  C  modules.  Thus,  the  intentions  of  one  module’s  implementor  may  affect  how  the  whole 
program  is  structured. 

It  is  worth  exploring  whether  ML  can  be  extended  with  a  more  flexible  and  explicit  notion 
of  implementor  (aka  “principal”  or  “agent”)  that  would  allow  the  implementor  of  one  module  to 
specify,  in  a  concise  and  local  manner,  how  different  principals  in  the  program  may  perceive  it. 
Grossman  et  al.  [24]  have  proposed  a  technique  for  syntactic  proofs  of  type  abstraction  properties 
in  the  setting  of  a  A-calculus  with  multiple  principals.  It  is  not  immediately  clear,  though,  how  to 
translate  their  calculus  into  a  language  design,  or  even  what  language  mechanisms  for  multi-agent 
data  abstraction  are  the  right  ones. 

Views  In  ML,  the  only  abstract  types  whose  elements  may  be  pattern-matched  are  those  intro¬ 
duced  by  datatype  definitions.  Furthermore,  although  a  datatype  is  an  abstract  type,  it  is  really 
“concrete”  in  the  sense  that  it  is  isomorphic  (via  its  in  and  out  coercions)  to  a  particular  sum  type. 
To  remedy  this  limitation,  Wadler  [80]  proposed  the  idea  of  views,  which  allow  the  programmer 
to  write  a  non-canonical  implementation  of  a  datatype  signature.  A  view  consists  of  two  trans¬ 
formation  functions:  one  from  the  datatype  to  the  actual  implementation  type,  which  is  called  at 
applications  of  the  datatype’s  constructors,  and  one  in  the  other  direction,  which  is  invoked  during 
pattern  matching. 

Views  afford  programmers  the  convenience  of  pattern  matching,  while  preserving  their  ability 
to  hide  the  identity  of  the  implementation  type.  As  such,  they  would  constitute  a  real  extension  to 
ML’s  support  for  data  abstraction.  Okasaki  has  proposed  a  variant  of  Wadler’s  views  in  the  context 
of  SML  [60],  but  only  informally.  It  would  be  useful  to  formalize  his  (or  perhaps  some  other)  view 
extension  using  the  Harper-Stone  framework. 
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Type  Classes  As  I  explained  at  the  beginning  of  Chapter  9,  my  language  deprecates  the  SML 
features  of  overloaded  equality  and  equality  types  because  I  believe  they  are  more  trouble  than 
they  are  worth.  A  general  mechanism  for  overloading,  though,  would  be  a  worthwhile  extension  to 
ML.  Originally  proposed  by  Wadler  and  Blott  [81]  as  a  way  of  generalizing  ML’s  equality  types, 
type  classes  enable  overloading  of  arbitrary  user-defined  functions  and  have  become  one  of  the  most 
popular  features  of  the  Haskell  language  [25]. 

Although  Haskell  type  classes,  like  ML  modules,  provide  support  for  code  reuse,  type  classes 
are  no  substitute  for  a  module  system,  and  vice  versa.  Type  classes  generalize  type  inference, 
whereas  modules  provide  program  structure  and  enforce  data  abstraction.  An  important  (and,  to 
my  knowledge,  unexplored)  direction  for  future  work  is  to  understand  better  how  these  features 
relate  to  each  other  and  how  they  might  interact  if  they  were  both  provided  by  a  single  language. 
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